Intent to Ship: The <geolocation> element

[Chromestatus]

Contact emails

andy...@google.com, lemi...@google.com, eng...@google.com

Explainer

https://github.com/WICG/PEPC/blob/main/explainer.md
https://github.com/WICG/PEPC/blob/main/geolocation_explainer.md

Specification

https://wicg.github.io/PEPC/permission-elements.html

Design docs

https://docs.google.com/document/d/1GyDZ9gq5ckrpLEr0l1xLM1kR-mxqWrS6LapwVa0mCLA/edit?tab=t.0#heading=h.bat9awopsp53

Summary

Introduces the <geolocation> element, a declarative, user-activated control for accessing the user's location. It streamlines the user and developer journey by not only handling the permission flow but also directly providing location data to the site, often eliminating the need for a separate JavaScript API call. This addresses the long-standing problem of permission prompts being triggered directly from JavaScript without a strong signal of user intent. By embedding a browser-controlled element in the page, the user's click provides a clear, intentional signal. This enables a much better prompt UX and, crucially, provides a simple recovery path for users who have previously denied the permission. Note: This feature was previously developed and tested in an Origin Trial as the more generic <permission> element. Based on feedback from developers and other browser vendors, it has evolved into the capability-specific <geolocation> element to provide a more tailored and powerful developer experience. Explainer: https://github.com/WICG/PEPC/blob/main/geolocation_explainer.md Instructions: https://github.com/WICG/PEPC/blob/main/HOWTO.md

Blink component

UI>Browser>Permissions>Prompts

Web Feature ID

permissions

Motivation

The current web permission model for geolocation relies on JavaScript-triggered prompts, giving the user agent no strong signal of user intent. This results in out-of-context prompts, user frustration, and difficult-to-recover-from denial states. We propose the <geolocation> element, a semantic HTML control with browser-controlled content and strict styling constraints. These constraints are fundamental to the security model, ensuring a very high level of confidence in the user's intent when making a permission decision at both the site and OS level. Crucially, the <geolocation> element evolves beyond simply managing permissions; it streamlines the entire journey by also directly providing location data to the site. This often eliminates the need for separate JavaScript API calls, simplifying implementation and creating a more seamless user flow. By providing a clear, consistent, in-page control, this element solves significant user problems related to context blindness and "permission regret," offering a simple recovery path from a previously denied state. The combination of a user-initiated element and a subsequent browser-controlled confirmation UI enhances intent capture, improves accessibility, and prevents manipulative patterns, providing a significantly better experience for both users and developers.

Initial public proposal

https://github.com/WICG/proposals/issues/113

TAG review

https://github.com/w3ctag/design-reviews/issues/1079 https://github.com/w3ctag/design-reviews/issues/1140

TAG review status

Issues addressed

Origin Trial Name

Page-embedded Permission Control (Camera/Mic)

Chromium Trial Name

PermissionElement

Origin Trial documentation link

https://github.com/WICG/PEPC/blob/main/explainer.md

WebFeature UseCounter name

kHTMLPermissionElement

Risks

Interoperability and Compatibility

There is a risk that this feature fails to be adopted by other browsers. This can be mitigated by backwards designing a reasonable fallback mechanism so that the element can degrade gracefully if the it's in an unsupported environment.

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/1288)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/545#issuecomment-3345403375)

Web developers: Positive (https://github.com/WICG/PEPC/issues/59) https://github.com/WICG/PEPC/issues/2#issuecomment-2393820279 https://github.com/WICG/PEPC/issues/2#issuecomment-2393861768 https://github.com/WICG/PEPC/issues/2#issuecomment-2393911331 https://github.com/WICG/PEPC/issues/2#issuecomment-2619657041

Other signals:

Ergonomics

No foreseen ergonomics risks.

Activation

A polyfill can help developers use this feature without risking broken functionality on non-supporting browsers.

Security

https://github.com/WICG/PEPC/blob/main/explainer.md#Security

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Feature is not shipping on WebView due to it requiring permission manager embedder support.

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No
The Geolocation Element is not supported on Android WebView as it requires permission manager support to function and the WebView permission manager defers most permission decisions to the embedder by design.

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/html/semantics/permission-element

DevTrial instructions

https://github.com/WICG/PEPC/blob/main/HOWTO.md

Flag name on about://flags

No information provided

Finch feature name

GeolocationElement

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

True

Tracking bug

https://b.corp.google.com/issues/435351699

Launch bug

https://launch.corp.google.com/launch/4428191

Availability expectation

Feature is available only in Chromium browsers. We are not aware of other browsers adoption.

Adoption expectation

Feature is used by specific partner(s) to provide functionality within 12 months of launch in Chrome. Partners who are tested the feature in OT are expected to continue usage.

Adoption plan

We are planning to publish on developer.chrome.com and do further partner outreach

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

No

Estimated milestones

Shipping on desktop	144
Origin trial desktop first	126
Origin trial desktop last	131
Origin trial extension 1 end milestone	134
Origin trial extension 2 end milestone	137
Origin trial extension 3 end milestone	140
Origin trial extension 4 end milestone	143
DevTrial on desktop	121
Shipping on Android	144
Origin trial Android first	134
DevTrial on Android	134

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

NA

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5125006551416832?gate=5202152317779968

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/TGsrhP4ref0/m/bHFj3id9AgAJ?utm_medium=email&utm_source=footer
Ready for Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/D-mE5qIlkWY
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFuQ4YuA5Fskj1QyrzL%2BXpZdQGe_vCu-wQjgqqhDwazC0Rr4FA%40mail.gmail.com
Intent to Extend Experiment 1: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALTCLq7M2xaMvR4xFUk29gAsLLUcmWBFqgKhwQfADrf%3DmniNHg%40mail.gmail.com
Intent to Extend Experiment 2: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/679cc50c.2b0a0220.243291.0754.GAE%40google.com
Intent to Extend Experiment 3: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/685d0e00.170a0220.291021.0232.GAE%40google.com
Intent to Extend Experiment 4: https://groups.google.com/a/chromium.org/g/blink-dev/c/z2ikrqboP3o

This intent message was generated by Chrome Platform Status.