#1140: Incubation: `<geolocation>` element (part of PEPC)

Visit on Github.

Opened Aug 20, 2025

Explainer

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

The explainer

Where and by whom is the work is being done?

  • GitHub repo: https://github.com/WICG/PEPC
  • Primary contacts:
    • Alexandru Paicu (@andypaicu), Google Chrome, Implementor
    • Daniel Vogelheim (@otherdaniel), Google Chrome, Spec Editor
  • Organization/project driving the design: Google Chrome
  • This work is being funded by: Google Chrome
  • Incubation and standards groups that have discussed the design:
  • Standards group(s) that you expect to discuss and/or adopt this work when it's ready: unknown

Feedback so far

You should also know that...

Important note: this is part of "permission" element proposal (https://github.com/w3ctag/design-reviews/issues/1079). Based on various discussions and feedback, we're proposing a split from a one-size-fits-all element to elements focused on specific capabilities. This is the proposal for a <geolocation> element. This element would inherit from the <permission> element all of its attributes, events, and checks. In the end the <permission> element would serve as a base class for the various capability-focused elements, and would no longer be usable directly.

<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1140

Discussions

Log in to see TAG-private discussions.

Discussed Sep 1, 2025 (See Github)

Martin: Suggest that we encourage them to continue. Apple might have reservations about duplicative work, but this is in a good shape.

Marcos: Main concern was the duplicative aspect of this. The positive is that it lets you recover from mistakes. Deny is difficult to unwind. This allows you to get back from that gracefully. The thing was that this is less of a concern in Safari, because of different choices in prompting. It is good because it becomes a nice element, but people might continue to use other things. The surprising was the restrictions on the element, which seem arbitrary. And difficult to implement. Could be wrong. Hiding/transparency all in the document, but need to be addressed and are quite tricky because they are trying to address click-jacking. iOS has a swift element, which is meaningless, because it can be restyled into meaninglessness. Is this going to be flexible enough for developers to use. Different presentation might not lead to consistent implementation and be adapted to suit every website. My sense is that this is going to fall apart because of the competing tensions.

Martin: I also share reservations about restrictions on styling and placement.

Marcos: Starting from a form element, which is less ambitious, this could really be a thing. I can also see some tweaks to make as a geolocation API editor, but minor stuff.

Marcos/Martin to put a comment together.

Discussed Sep 8, 2025 (See Github)

Lola: Doesn't seem like anyone else brainstormed further.

Matthew: We've discussed last week but didn't make it to the issue.

Comment by @andypaicu Sep 24, 2025 (See Github)

At this point we would like to request a full TAG review for the <geolocation> element. Should I raise another issue or can this issue be adapted?

Comment by @jyasskin Sep 24, 2025 (See Github)

We can use this one, but please look through https://github.com/w3ctag/design-reviews/issues/new?template=015-other-spec-review.yaml and add any information that's not already in your original post, especially a link to your specification. It would also be ideal if a WG adopted this before we try to review the full spec. Have you proposed it to, say, WebAppSec?

Comment by @martinthomson Sep 25, 2025 (See Github)

Isn't this more appropriately in the DaS scope?

Comment by @jyasskin Sep 25, 2025 (See Github)

Isn't this more appropriately in the DaS scope?

Maybe! It kinda crosses the boundary, so the team should probably pitch it to both.

Discussed Sep 29, 2025 (See Github)

Matthew: Proponents have asked for a full TAG review. Marcos: Since Martin and Lola are not here, is anyone interested? Matthew: Marcos, anything specific you would like to add? Marcos: Worried about the duplicative nature, and the element does two roles: Permission and location updates. … Do we want these elements to have the same behavior as the Geolocation API or not? … Or should it just use the permissions? Cool thing is that they would participate in forms submission. … At the same time, also somewhat unneccessary. … Should they just be permission enabling things? … How dynamic is it? How would you style it? A bunch of things that is not yet clear. Matthew: It would be great if we collect the points that we already have consensus on. … Can you draft a comment in the private brainstorming? … And if we get that agreed during the rest of this week, we could post this? Marcos: Yes.

Comment by @marcoscaceres Oct 2, 2025 (See Github)

It's in scope of Web Apps WG jointly with DaS.

Comment by @marcoscaceres Oct 2, 2025 (See Github)

WebKit position (or at least initial questions and concerns) https://github.com/WebKit/standards-positions/issues/545

Discussed Oct 6, 2025 (See Github)

Lola: any update?

Matthew: I need more time on this.

Lola: was it discussed last week? there seems to some discussions

Matthew: yes.