Request for position on the "Geolocation element" (part of PEPC)

[MinhAnhL]

WebKittens

@marcoscaceres, @annevk

Title of the proposal

Geolocation element (PEPC)

URL to the spec

In progress

URL to the spec's repository

No response

Issue Tracker URL

No response

Explainer URL

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

TAG Design Review URL

No response

Mozilla standards-positions issue URL

No response

WebKit Bugzilla URL

No response

Radar URL

No response

Description

This is a separate request specifically just for the element which is part of the larger umbrella of the PEPC feature.

We have separated the "permission" element into separate elements (each focused on one capability) based on recent feedback and discussions. This position request is for the element, which focuses the "device location" capability, mirroring the getCurrentPosition or watchPosition APIs, while keeping the advantages of PEPC.

The element (with its existing attributes, events, and checks) will remain as the base common class for each of these elements, but would no longer be usable directly, therefore I've also included the old explainer for the permission element.

Relevant context:
Page Embedded Permission Control (PEPC) #270
Page Embedded Permission Control #908
Proposal for a element #59

[annevk]

Thank you for filing this request! While overall we like building a slightly more declarative future, we found a number of issues with this proposal that we could not reconcile with the rest of the web platform:

• Limited styling of an in-page control is in direct opposition to the appearance: base effort of making all HTML controls fully styleable by web developers.
• Limiting styling of controls has historically not gone too well and has been a huge frustration to web developers.
• The adoption carrot is rather weak. This will allow end users to undo a potentially bad decision using an in-page control rather than website settings.
• It's not clear that given that rather small benefit, building out this complex control that ends up being inconsistent with all other controls is worth it.
• It's not entirely evident to us that the issues with existing permission dialogs outlined in the explainers are valid across implementations. E.g., in implementations where permissions are not persisted as often, a refresh can be all that is needed to get back to a desired state.
• The clickjacking defense depends upon a v2 feature of IntersectionObserver — occlusion — that is not actually defined (perhaps because hit testing is not defined).

[MinhAnhL]

Thanks for your feedback and questions, Anne!

• Limited styling of an in-page control is in direct opposition to the appearance: base effort of making all HTML controls fully styleable by web developers.
• Limiting styling of controls has historically not gone too well and has been a huge frustration to web developers.

This concern is reasonable. The proposal does impose a set of limitations on the ways in which the element can be styled, and developers might indeed find those limitations frustrating.

At core, the goal is to ensure that users see pixels that we believe provide meaningful context before we ask them to make a decision about a sensitive capability. Ideally, this will lead to better decision-making by users who are signaling intent to engage in the kind of decision we present. I think we're very open to alternatives, but the clearest way we've found to provide that assurance is to control the visibility and the content of the rendered element.

Are there particular limitations that you'd point to as being especially frustrating for developers? Could you perhaps help us gather feedback from folks on Apple's iOS team about their experience with similar constraints on controls like LocationButton? We'd love to learn from their experience.

• The adoption carrot is rather weak. This will allow end users to undo a potentially bad decision using an in-page control rather than website settings.

Case studies from our origin trial of an earlier version of this proposal suggests that developers find this valuable.

• It's not clear that given that rather small benefit, building out this complex control that ends up being inconsistent with all other controls is worth it.

Ideally, we wouldn't think of this as a one-off that's distinct from all other controls, but a pattern we'd like to extend across a broader spectrum of capabilities. As we develop those mechanisms and gain confidence in the pattern, it would be quite reasonable to introduce more friction for flows where we don't have the same strong signal of user interest and/or understanding. That seems like a good direction for the platform generally, and would allow us to generally be more opinionated when defending our users from distraction and abuse.

• It's not entirely evident to us that the issues with existing permission dialogs outlined in the explainers are valid across implementations. E.g., in implementations where permissions are not persisted as often, a refresh can be all that is needed to get back to a desired state.

I think all browsers have developed heuristics in slightly different directions around permissions requests, forcing them to make a difficult trade-off. A browser can be stricter to protect users from spam, but this inevitably creates “false negatives” where legitimate requests are blocked. Conversely, a browser can be more lenient to ensure users can always grant a permission, but this comes at the direct costs of exposing users to more unwanted prompts.

This is precisely where our proposal offers a solution for the entire platform. By shifting towards a model that relies on a strong, user-initiated signal, we can break this fundamental trade-off. It allows a browser to be extremely opinionated in defending users from spammy, out of context requests., while still providing a clear and reliable path for users to grant permissions when they have clear intent. This is a better direction for the platform generally, reducing both user frustration and annoyance.

• The clickjacking defense depends upon a v2 feature of IntersectionObserver — occlusion — that is not actually defined (perhaps because hit testing is not defined).

You're right that the current definition is somewhat implementation-defined. If more detail would be helpful for compatibility, that sounds like a great thing to collaborate on! Independent of the feature we're discussing here, it'd be fantastic to generally see more support for Intersection Observer v2. :)