新しい HTML 要素のオリジン トライアル

Thomas Steiner

ウェブアプリで位置情報へのアクセスなどの強力な機能を使用する権限を求めるための命令型メソッドがいくつかあります。これらのメソッドには多くの課題があるため、Chrome 権限チームは新しい宣言型メソッド（専用の HTML <permission> 要素）を試験運用しています。この要素は Chrome 126 からオリジン トライアルで提供されており、最終的には標準化されることが期待されています。

権限をリクエストする命令型メソッド

ウェブアプリが強力な機能にアクセスする必要がある場合は、権限をリクエストする必要があります。たとえば、Google マップが Geolocation API を使用してユーザーの位置情報を必要とする場合、ブラウザはユーザーに確認を求め、多くの場合、その決定を保存するオプションが表示されます。これは、Permissions 仕様で明確に定義されたコンセプトです。

初回使用時に暗黙的に尋ねるか、事前に明示的にリクエストするか

Geolocation API は強力な API であり、初回使用時に暗黙的に尋ねるアプローチに依存しています。たとえば、アプリが navigator.geolocation.getCurrentPosition() メソッドを呼び出すと、最初の呼び出し時に権限プロンプトが自動的にポップアップします。別の例として、navigator.mediaDevices.getUserMedia() が挙げられます。

Notification API や Device Orientation and Motion API などの他の API には、Notification.requestPermission() や DeviceMotionEvent.requestPermission() などの静的メソッドを介して権限をリクエストする明示的な方法が用意されているのが一般的です。

権限を求める命令型メソッドの課題

権限スパム

以前は、ウェブサイトが読み込まれると、ウェブサイトは navigator.mediaDevices.getUserMedia() や Notification.requestPermission() などのメソッドだけでなく、navigator.geolocation.getCurrentPosition() もすぐに呼び出すことができました。ユーザーがウェブサイトを操作する前に、権限のプロンプトが表示されます。これは権限スパムと呼ばれることもあり、初回使用時に暗黙的に尋ねる方法と、事前に明示的にリクエストする方法の両方に影響します。

ブラウザの緩和策とユーザー操作の要件

権限スパムにより、ブラウザ ベンダーは権限プロンプトを表示する前に、ボタンのクリックやキーダウン イベントなどのユーザー操作を要求するようになりました。このアプローチの問題は、特定のユーザー操作で権限プロンプトを表示するかどうかをブラウザが判断することが非常に難しいことです。ページの読み込みに時間がかかったため、ユーザーがイライラしてページ上のどこかをクリックしたのかもしれません。あるいは、実際に [現在地] ボタンをクリックしたのかもしれません。また、一部のウェブサイトでは、ユーザーがコンテンツをクリックしてプロンプトをトリガーするように誘導する手口が巧妙化しています。

別の緩和策として、プロンプトの不正使用を緩和する対策を追加することもできます。たとえば、最初から機能を完全にブロックしたり、権限プロンプトをモーダルではない、より控えめな方法で表示したりします。

権限のコンテキスト化

特に大画面では、権限プロンプトが一般的に表示される方法も課題となります。権限プロンプトは、ライン オブ デス（アプリが描画できるブラウザ ウィンドウの領域の外側）の上に表示されます。ユーザーがウィンドウの下部にあるボタンをクリックした直後に、ブラウザ ウィンドウの上部に表示されたプロンプトを見逃すことは珍しくありません。この問題は、ブラウザのスパム対策が有効になっていると悪化することがよくあります。

簡単に元に戻すことはできません

最後に、ユーザーが簡単に行き止まりに迷い込んでしまうことです。たとえば、ユーザーが機能へのアクセスをブロックすると、サイト情報のプルダウンで [権限をリセット] を選択するか、ブロックされた権限を再度有効にする必要があります。どちらのオプションも、最悪の場合、更新された設定が有効になるまでページの完全な再読み込みが必要になります。サイトには、ユーザーが既存の権限の状態を簡単に変更できるショートカットを提供する機能がなく、次の Google マップのスクリーンショットの下部に示すように、ユーザーに設定の変更方法を丁寧に説明する必要があります。

権限がエクスペリエンスの鍵となる場合（ビデオ会議アプリのマイクへのアクセスなど）、Google Meet などのアプリは、権限のブロックを解除する方法をユーザーに指示する、邪魔なダイアログを表示します。

宣言型の <permission> 要素

この投稿で説明した課題に対処するため、Chrome の権限チームは新しい HTML 要素 <permission> のオリジン トライアルを開始しました。この要素を使用すると、デベロッパーは、ウェブサイトで利用できる強力な機能のサブセットの使用権限を宣言的にリクエストできます。最も単純な形式では、次の例のように使用します。

<permission type="camera" />

<permission> を空要素にするかどうかについては、現在も活発な議論が続いています。空要素は、子ノードを持つことができない HTML の自己終了要素です。HTML では、終了タグがないことを意味します。

type 属性

type 属性には、リクエストする権限のスペース区切りのリストが含まれます。このドキュメントの作成時点では、指定できる値は 'camera'、'microphone'、camera microphone です（スペースで区切ります）。この要素は、デフォルトでは、ユーザー エージェントの基本的なスタイル設定が適用されたボタンと同様にレンダリングされます。

type-ext 属性

追加のパラメータを許可する一部の権限では、type-ext 属性は、スペースで区切られた Key-Value ペアを受け入れます。たとえば、位置情報権限の precise:true などです。

lang 属性

ボタンのテキストはブラウザによって提供され、一貫性を保つことを目的としているため、直接カスタマイズすることはできません。ブラウザは、ドキュメントまたは親要素チェーンの継承された言語、またはオプションの lang 属性に基づいて、テキストの言語を変更します。つまり、デベロッパーが <permission> 要素を自分でローカライズする必要はありません。<permission> 要素がオリジン トライアルの段階を超えて進む場合、柔軟性を高めるために、権限タイプごとに複数の文字列またはアイコンがサポートされる可能性があります。<permission> 要素の使用に関心があり、特定の文字列やアイコンが必要な場合は、お問い合わせください。

動作

ユーザーが <permission> 要素を操作すると、さまざまなステージを切り替えることができます。

• 以前に機能を許可していない場合は、すべてのアクセスで許可するか、今回のアクセスのみで許可するかを選択できます。

  

• 以前にこの機能を許可していた場合は、引き続き許可するか、許可を停止できます。

  

• 以前に機能を許可しなかった場合、引き続き許可しないことも、今回許可することもできます。

  

<permission> 要素のテキストは、ステータスに基づいて自動的に更新されます。たとえば、機能の使用が許可された場合、テキストは機能が許可されたことを示すように変更されます。権限の付与が最初に必要な場合は、ユーザーに機能の使用を促すテキストに変わります。前のスクリーンショットと次のスクリーンショットを比較して、2 つの状態を確認します。

CSS デザイン

ユーザーがボタンを強力な機能にアクセスするためのサーフェスとして簡単に認識できるように、<permission> 要素のスタイル設定は制限されています。スタイルの制限がお客様のユースケースで機能しない場合は、その理由と方法についてぜひお聞かせください。すべてのスタイリングのニーズに対応できるわけではありませんが、オリジン トライアル後に <permission> 要素のスタイリングをさらに許可する安全な方法を見つけたいと考えています。次の表に、制限または特別なルールが適用されるプロパティの詳細を示します。いずれかのルールに違反した場合、<permission> 要素は無効になり、操作できなくなります。このオブジェクトを操作しようとすると、JavaScript でキャッチできる例外が発生します。エラー メッセージには、検出された違反の詳細が記載されます。

次の CSS プロパティは通常どおり使用できます。

• font-kerning
• font-optical-sizing
• font-stretch
• font-synthesis-weight
• font-synthesis-style
• font-synthesis-small-caps
• font-feature-settings
• forced-color-adjust
• text-rendering
• align-self
• anchor-name aspect-ratio
• border（およびすべての border-* プロパティ）
• clear
• color-scheme
• contain
• contain-intrinsic-width
• contain-intrinsic-height
• container-name
• container-type
• counter-*
• flex-*
• float
• height
• isolation
• justify-self
• left
• order
• orphans
• outline-*（outline-offset の例外については前述のとおり）
• overflow-anchor
• overscroll-behavior-*
• page
• position
• position-anchor
• content-visibility
• right
• scroll-margin-*
• scroll-padding-*
• text-spacing-trim
• top
• visibility
• x
• y
• ruby-position
• user-select
• width
• will-change
• z-index

また、論理的に同等のプロパティ（inline-size は width と同等など）はすべて、同等のプロパティと同じルールに従って使用できます。

疑似クラス

状態に基づいて <permission> 要素のスタイルを設定できる特別な疑似クラスが 2 つあります。

• :granted: :granted 疑似クラスを使用すると、権限が付与されたときに特別なスタイル設定が可能になります。
• :invalid: :invalid 疑似クラスを使用すると、要素が無効な状態（クロスオリジン iframe で配信されている場合など）のときに特別なスタイル設定を行うことができます。

permission {
  background-color: green;
}

permission:granted {
  background-color: light-green;
}

/* Not supported during the origin trial. */
permission:invalid {
  background-color: gray;
}

JavaScript イベント

<permission> 要素は、Permissions API と組み合わせて使用することを想定しています。リッスンできるイベントは多数あります。

• onpromptdismiss: このイベントは、要素によってトリガーされた権限プロンプトがユーザーによって閉じられたときに（閉じるボタンをクリックしたり、プロンプトの外側をクリックしたりするなど）、発生します。

• onpromptaction: このイベントは、要素によってトリガーされた権限プロンプトが、ユーザーがプロンプト自体に対して何らかのアクションを行ったことで解決されたときに発生します。必ずしも権限の状態が変更されたことを意味するわけではありません。ユーザーが現状を維持するアクション（権限の許可を継続するなど）を行った可能性もあります。

• onvalidationstatuschange: このイベントは、要素が "valid" から "invalid" に切り替わったときに発生します。ブラウザがユーザーがクリックした場合のシグナルの完全性を信頼できる場合は、要素は "valid" と見なされます。それ以外の場合は "invalid" と見なされます（要素が他の HTML コンテンツによって部分的に隠されている場合など）。

これらのイベントのイベント リスナーは、次の例に示すように、HTML コード（<permission type="…" onpromptdismiss="alert('The prompt was dismissed');" />）で直接インラインで登録するか、<permission> 要素で addEventListener() を使用して登録できます。

<permission type="camera" />
<script>
  const permission = document.querySelector('permission');
  permission.addEventListener('promptdismiss', showCameraWarning);

  function showCameraWarning() {
    // Show warning that the app isn't fully usable
    // unless the camera permission is granted.
  }

  const permissionStatus = await navigator.permissions.query({name: "camera"});
  
  permissionStatus.addEventListener('change', () => {
    // Run the check when the status changes.
    if (permissionStatus.state === "granted") {
      useCamera();
    }
  });

  // Run the initial check.
  if (permissionStatus.state === "granted") {
    useCamera();
  }
</script>

特徴検出

ブラウザが HTML 要素をサポートしていない場合、その要素は表示されません。つまり、HTML コードに <permission> 要素があっても、ブラウザがそれを認識しない場合は何も起こりません。たとえば、通常の <button> のクリックでトリガーされる権限プロンプトを作成するために、JavaScript を使用してサポートを検出する必要がある場合があります。

if ('HTMLPermissionElement' in window) {
  // The `<permission>` element is supported.
}

オリジン トライアル

実際のユーザーを対象にサイトで <permission> 要素を試すには、オリジン トライアルに登録します。オリジン トライアルを使用するためのサイトの準備手順については、オリジン トライアルのスタートガイドをご覧ください。オリジン トライアルは Chrome 126 から 131（2025 年 2 月 19 日）まで実施されます。

デモ

デモを試し、GitHub でソースコードを確認してください。対応ブラウザでのエクスペリエンスのスクリーンショットを以下に示します。

フィードバック

<permission> がお客様のユースケースでどのように機能するかについて、ぜひお聞かせください。リポジトリの問題のいずれかに返信するか、新しい問題を提出してください。<permission> 要素の repo 内の公開シグナルにより、Google や他のブラウザに、あなたがこの要素に関心があることを知らせることができます。

よくある質問

• 通常の <button> と Permissions API を組み合わせるよりも優れている点は何ですか？<button> のクリックはユーザー ジェスチャーですが、ブラウザには、それが権限のリクエストに関連付けられていることを確認する方法がありません。ユーザーが <permission> をクリックした場合、ブラウザはクリックが権限リクエストに関連していることを確認できます。これにより、ブラウザは、そうでない場合はリスクがはるかに高くなるフローを促進できます。たとえば、ユーザーが権限のブロックを簡単に元に戻せるようにします。
• 他のブラウザが <permission> 要素をサポートしていない場合はどうなりますか？<permission> 要素はプログレッシブ エンハンスメントとして使用できます。サポートされていないブラウザでは、従来の権限フローを使用できます。たとえば、通常の <button> のクリックに基づいて、権限チームもポリフィルの開発に取り組んでいます。準備が整い次第通知を受け取るには、GitHub リポジトリにスターを付けます。
• 他のブラウザ ベンダーとこの件について話し合いましたか？<permission> 要素は、2023 年の W3C TPAC のブレイクアウト セッションで活発に議論されました。公開セッションのメモを読むことができます。Chrome チームは、両方のベンダーに正式な標準ポジションも求めています。関連リンクのセクションをご覧ください。<permission> 要素は他のブラウザとの間で継続的に議論されているトピックであり、標準化が期待されています。
• これは実際には空要素であるべきですか？<permission> を空要素にするかどうかについては、現在も活発な議論が続いています。フィードバックがある場合は、Issue にコメントしてください。

関連リンク

• 説明する人
• WebKit の標準化への取り組み
• Mozilla Standards Position

謝辞

このドキュメントは、Balázs Engedy、Thomas Nguyen、Penelope McLachlan、Marian Harbach、David Warren、Rachel Andrew によってレビューされました。