<geolocation> HTML 要素の導入

公開日: 2026 年 1 月 13 日

Chrome 144 以降では、新しい <geolocation> HTML 要素を使用できます。この要素は、サイトがユーザーの位置情報をリクエストする方法の大きな変化を表しています。スクリプトでトリガーされる権限プロンプトから、宣言的でユーザー アクション指向のエクスペリエンスに移行します。これにより、権限の状態とエラーの処理に必要なボイラープレート コードが削減され、ユーザーの意図をより強く示すシグナルが提供されるため、ブラウザの介入(サイレント ブロックなど)を回避できます。

このリリースは、広範な実環境でのテストと、ウェブ標準コミュニティとの厳格な議論の結果です。この要素の有用性を理解するには、その開発の経緯と、その設計を推進したデータを検証することが重要です。

汎用 <permission> から特定の <geolocation>

<geolocation> 要素は、ページ埋め込み権限制御イニシアチブの最新の進化形です。このイニシアチブでは、当初は type 属性を持つ汎用的な <permission> 要素として提案されました(元の説明を参照)。type 属性の値("geolocation" など)によって、リクエストされた権限のタイプが決まります。たとえば、最初の提案には、カメラ、マイク、位置情報などの値が含まれます。

コンセプトの検証

Chrome 126 ~ 143 で、汎用 <permission> 要素のオリジン トライアルを実施しました。このテストの目的は、専用のコンテキスト内ボタンがユーザーの信頼と意思決定を向上させるという仮説を検証することでした。

このオリジン トライアルの結果は、このコアコンセプトの検証をサポートしました。

  • Zoom は、この要素を使用してユーザーを復元に誘導することで、カメラまたはマイクのキャプチャ エラー(システムレベルのブロッカーなど)が 46.9% 減少したと報告しています。
  • Immobiliare.it では、位置情報フローの成功率が 20% 増加しました。
  • ZapImóveis は、要素が表示されたときに「以前にブロックされた」状態から回復したユーザーの成功率が 54.4% であることを確認しました。

設計の再定義

コンセプトは成功しましたが、実装には改善が必要でした。Apple(Safari/WebKit)Mozilla(Firefox)などのブラウザ ベンダーからのフィードバックによると、「万能」な要素は、独自の機能の動作に関して大きな複雑さを生み出していました。

その結果、汎用的な権限制御から、特定の機能に特化した要素に移行しました(WICG のディスカッションを参照)。<geolocation> 要素は、これらの特殊なコントロールのうち最初にリリースされるものです。これに続いて、専用の <usermedia> 要素(カメラとマイクへのアクセス用)も開発しています。この要素には、独自の独立したオリジン トライアルがあります。

権限の状態(許可または拒否)の管理に重点を置いていた元の提案とは異なり、これらの新しい要素はデータ メディエータとして機能し、ほとんどのユースケースで JavaScript API を直接呼び出す必要性を効果的に置き換えます。

次の表に、Geolocation JavaScript API、<permission> 要素、新しい <geolocation> 要素の違いを示します。
機能 Geolocation JS API <permission> HTML 要素 <geolocation> HTML 要素
権限プロンプトのトリガーとなるイベント 命令型スクリプトの実行(getCurrentPosition ユーザーがブラウザ制御の <permission> 要素をクリックする ユーザーがブラウザ制御の <geolocation> 要素をクリックする
ブラウザのロール 状態に基づいてプロンプトを決定する 権限の仲介役として機能する データ メディエータとして機能する
サイトの責任 JavaScript API を手動で呼び出し、コールバックを処理して権限エラーを管理する 権限が付与されたら geolocation API を実装する location イベントをリッスンする
コア目標 基本的な位置情報へのアクセス 権限のリクエスト 権限のリクエストと位置情報へのアクセス

<geolocation> 要素を使用する理由

現在、位置情報フローは Geolocation API に依存しています。この API は、コンテキスト外で、またはページの読み込み時に起動されると、ユーザーを中断する可能性のある権限プロンプトをトリガーします。重要なのは、ブラウザの介入により、これらの命令型プロンプトへの依存が実現しにくくなっていることです。たとえば、ユーザーがプロンプトを 3 回閉じた場合、Chrome は権限リクエストを積極的にブロックし、最初は 1 週間続く一時的なサイレント ブロックを適用します。つまり、プロンプトをトリガーしようとするレガシーコードがサイレントに失敗し、ユーザーは機能が動作しないまま、機能を有効にする方法もわからない状態になる可能性があります。また、標準的なプロンプトにはコンテキストが欠けていることがよくあります。プロンプトが予期せず表示された場合、ユーザーは反射的に、または誤ってブロックすることがあります。この決定により、取り消しが難しい永続的なブロックが作成されることをユーザーは認識していません。このコンテキストのギャップが、機能自体ではなく、高い不承認率の主な原因となっています。

<geolocation> 要素は、リクエストがユーザーによって厳密に開始されるようにすることで、コンテキストのギャップの問題を解決します。このモデルには、次の 3 つの利点があります。

  • 明確なインテントとタイミング: [位置情報を使用] ボタンをクリックすることで、ユーザーは特定のタイミングで位置情報を使用するインテントを明示的に示します。これは、ユーザーが位置情報の価値を理解し、積極的に使用したいと考えていることを示しており、ブロックされる可能性があったものが、成功したインタラクションに変わります。
  • 復元を簡素化: サイトの閲覧中にユーザーが位置情報へのアクセスをブロックした場合(誤ってブロックした場合や、コンテキストが不足している場合など)、要素をクリックすると、専用の復元フローがトリガーされます。これにより、ブラウザのサイト設定を深く掘り下げることなく、位置情報を実際に使用したいときに位置情報を再度有効にできます。
  • 自動更新: 権限がすでに付与されている場合、要素をクリックすると更新ボタンとして機能し、再プロンプトなしで新しいデータがすぐに取得されます。

実装

この要素を統合するには、JavaScript API よりもはるかに少ないボイラープレートが必要です。コールバックとエラー状態を手動で管理する代わりに、デベロッパーはタグをページに追加して onlocation イベントをリッスンできます。

<geolocation
  onlocation="handleLocation(event)"
  autolocate
  accuracymode="precise">
</geolocation>
function handleLocation(event) {
  // Directly access the GeolocationPosition object on the element
  if (event.target.position) {
    const { latitude, longitude } = event.target.position.coords;
    console.log("Location retrieved:", latitude, longitude);
  } else if (event.target.error) {
    console.error("Error:", event.target.error.message);
  }
}

主な属性とプロパティ

  • autolocate: 要素の読み込み時に位置情報の取得を自動的に試みますが、現在の権限ステータスで許可されている場合に限ります(予期しないプロンプトの表示を防ぎます)。
  • accuracymode: 標準の enableHighAccuracy オプションに対応する "precise" または "approximate" の値を受け入れます。
  • watch: watchPosition() に合わせて動作を切り替え、ユーザーの移動に合わせてイベントを継続的に発生させます。
  • position: DOM 要素の読み取り専用プロパティ。利用可能になると GeolocationPosition オブジェクトを返します。
  • error: リクエストが失敗した場合に GeolocationPositionError を返す読み取り専用プロパティ。

スタイルの制約

ユーザーの信頼を確保し、不正なデザイン パターンを防ぐため、<geolocation> 要素には、以前の <permission> 要素のテストと同様の特定のスタイルの制限が適用されます。ボタンはサイトのテーマに合わせてカスタマイズできますが、ブラウザにはいくつかのガードレールが適用されます。

  • 読みやすさ: 権限リクエストが常に読みやすいように、テキストと背景の色のコントラストが十分であるか(通常は 3:1 以上の比率)がチェックされます。また、要素が透明に見えないように、アルファ チャンネル(不透明度)を 1 に設定する必要があります。
  • サイズと間隔: 要素は、幅、高さ、フォントサイズの最小値と最大値の境界を適用します。要素が視覚的に隠れたり、他のコンテンツと重なって誤解を招くような表示になったりするのを防ぐため、負のマージンやアウトライン オフセットは無効になっています。
  • 視覚的な完全性: 歪み効果は制限されます。たとえば、変換は 2D 変換と比例スケーリングのみをサポートします。
  • CSS 疑似クラス: 要素は、:granted(権限が有効な場合)などの状態ベースのスタイル設定をサポートしています。

プログレッシブ エンハンスメント戦略

新しい HTML 要素の標準化は段階的なプロセスであることを理解しています。ただし、デベロッパーは、他のブラウザのユーザーとの互換性を損なうことなく、今日から <geolocation> 要素を採用できます。

この要素は、グレースフル デグラデーションとなるように設計されています。<geolocation> 要素をサポートしていないブラウザは、HTMLUnknownElement として扱います。重要な点として、ブラウザがこの要素をサポートしている場合、子要素はレンダリングされません。これにより、サポートされているブラウザとサポートされていないブラウザの両方で HTML をクリーンに記述できます。

カスタム フォールバック パターン

フォールバック エクスペリエンスを完全に制御したい場合は、通常の JavaScript Geolocation API にフックするボタンなどの子要素を使用できます。

<geolocation onlocation="updateMap()">
  <!-- Fallback contents if the element is not supported -->
  <button onclick="navigator.geolocation.getCurrentPosition(updateMap)">
    Use my location
  </button>
</geolocation>

デモ

3 種類の構成をテストするボタンがキャプションにリンクされているデモ。
<geolocation> 要素のデモ。3 つの主な構成(手動リクエスト、自動リクエスト(自動位置情報を使用)、位置情報のモニタリング(モニタリングを使用))を示しています。これらの動作は、ライブデモページでテストできます。

ポリフィル

代わりに、npm からポリフィルをインストールすることもできます。このポリフィルは、<geolocation> のすべての出現箇所を、通常の JavaScript Geolocation API に基づくカスタム要素 <geo-location>(ダッシュに注意)に透過的かつ自動的に置き換えます。ブラウザが <geolocation> 要素をサポートしている場合、ポリフィルは何も行いません。ポリフィルの動作を示す polyfill デモをご覧ください。ソースコードは GitHub にあります。

if (!('HTMLGeolocationElement' in window)) {
  await import('https://unpkg.com/geolocation-element-polyfill/index.js');
}
<geolocation onlocation="updateMap()"></geolocation>

特徴検出

より複雑なロジックの場合は、インターフェースを使用してサポートをプログラムで検出できます。

if ('HTMLGeolocationElement' in window) {
  // Use modern <geolocation> element logic
} else {
  // Fallback to legacy navigator.geolocation API
}

まとめ

デベロッパーが新しい <geolocation> HTML 要素を使用して、よりパフォーマンスの高い位置情報の再試行シナリオを実装することを期待しています。これは、ユーザーが実際にウェブを使用する方法に合わせて調整された、機能固有の要素への移行を表しています。

その他の権限のユースケースについては、Chrome 144 以降で <usermedia> HTML 要素のオリジン トライアルに参加することで、カメラとマイクにも同じ人間工学的なメリットをもたらすことができます。

謝辞

このドキュメントは、Andy Paicu、Gilberto Cocchi、Rachel Andrew によってレビューされました。