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.

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

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

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.

Lola: any update?

Matthew: I need more time on this.

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

Matthew: yes.

Marcos: Given it's a new paradigm that we'd be introducing to the web, I see a lot of issues with how it's specified right now - it needs a bit of work. I think we should discuss it at TPAC as a general model. It doesn't add a lot of value, and the mitigations that are in place are not implementable. But the underlying model has some merit. It's whether we continue on and pursue this path or not.

Hadley: They opened this in August. Are they OK with us waiting until TPAC?

Marcos: I think they have to be - they know this is a radical proposal. it's a pretty radical shift aware from the web's permission model. It solves for re-prompting but it doesn't solve for error recovery. If I haven installed web app, and the user denies the permission. On iOS it would not be possible to re-prompt if the user goes back to it later. You can't change OS-level permissioning. So from that perspective it's not implementable, at least on Apple's platforms. Some of the other issues I already outlined in the private thread. The utiltiy of the element is limited by the need to re-prompt when the user interacts with it. Also how they're using events is a bit confusion.

Hadley: Where at TPAC are we going to discuss this?

Marcos: Possibly in the DAS and Web Apps joint meeting. I can put on my TAG hat there. That seems the most efficient way. There are larger discussions around this - this has implications for the platform. Similar for the Web Install in Web Apps.

Marcos: For accessibility the promting is similar to how it is now. But in terms of UA considerations and the wider shift in the platform that it represents, it will be an interesting discussion.

Marcos: Discussion at TPAC: https://www.w3.org/events/meetings/4a477bab-4672-4d26-a890-49420725079f/ Wednesday 13 November 2025, 09:00–12:30 Japan Standard Time

Jeffrey: Marcos posted concerns to the issue that there would be discussions at TPAC, maybe we should come back to this after TPAC.

Martin: I drafted a comment. General view is positive, worth doing. it's a direction we'd like to see them continue to explore, but there is feedback about finishing things. Jeffrey has agreed. Lola, can you look at it?

Lola: ok.

Martin: if it does, poke me and I'll post it. Am OK with others posting instead. Mark as validated.

Jeffrey: They have a specification now: https://wicg.github.io/PEPC/permission-elements.html#geolocation-element

Marcos: Overall question of using this design for powerful features.

Martin: Team wants to ensure the element is on-screen when the person gives permission. Don't think it's sufficient, and they're building it to link into IntersectionObserver. Can't be activated off-screen.

Marcos: Need to check they're re-using geolocation machinery.

Martin: Yes, they are.

Jeffrey: Marcos had mentioned that IntersectionObserver isn't fleshed out enough, and would need to be finished to be used here.

Martin: Don't think it's necessary: just the fact that you click something on the page helps a lot.

Jeffrey: UAs might need to differ here. If rejections are sticky, UA might want to be confident the user saw something in particular. But if rejections aren't sticky, UA could accept many more "clicks". Do we have opinions on how?

Marcos: Amount of variance you can do might be huge. There's generated content from the element itself. Does that count as occlusion? Occlusion, style limitations, are a very hard problem.

Jeffrey: Does it work for that to be UA-defined?

Marcos: Should be ok.

Martin: Have to implement it to be sure. What it looks like on the screen, how user interactions work in your particular thing. It won't be done until there are 3-4 implementations that each take a different path. Uncomfortable how much it integrates with the permission element.

Jeffrey: So you want it split out more so it's clear we can delete the <permission> element?

Martin+Marcos: yes.

Martin: Do think the internal state is potentially re-usable. Not sure you'd do it to start with.

Jeffrey: So we advise them to wait on that until they define at least the <usermedia> element, and probably the third instance.

Jeffrey: I can draft a comment: 1) Generally support the direction. 2) Be sure this matches other form elements. 3) Allow UAs to vary on how much they restrict style and observability. 4) Define <geolocation> as its own thing, without trying to extract out "common" parts.

Martin: How does error stuff interact with form validation?

Marcos: I looked it up a couple weeks ago; don't remember the details. If you get an error, it's not validated.

Martin: Does it have :valid and :invalid CSS?

Marcos: Yes, that'll be set as well.

Jeffrey: No point in bringing up detailed validation of particular locations until someone proposes it.