To separate general feedback from PR feedback from #7 I will pull out the general points of feedback in this issue. @marcoscaceres feel free to review to make sure that I have correctly captured the feedback points. I hope I have captured/summarized everything correctly.

Summary of feedback points:

1. In regards to the issue of prompt position, and how it might be far from where the user's current visual focus is:
   There are options to address this in different ways than the explainer proposal. For example, permission requests on Apple platforms are increasingly handled at the OS level and using a modal prompt.

2. In regards to the issue of regret and the user not finding it easy to revisit old settings:
   This might be able to be addressed at the browser level, by finding UX that makes the surface more discoverable. If the surface was more discoverable this would not be such a big issue. Native apps solve this by allowing the user to go directly from the application to the permission sheet.

3. In regards to accessibility considerations:
   An HTML element could improve accessibility by being easier to discover and navigate to, if screen readers implement this functionality.

4. In regards to benefits of having an HTML button and the benefits of it being non-interruptive, discoverable and providing contextual information:
   This can already be achieved with a <button> control in today's status quo if sites wish to implement it this way.

5. In regards to customization options:
   5.1) Allowing too much customization will make the button meaningless of extracting user intent as it can take so many forms that users will not be able to recognize it's shared purposed across various sites
   5.2) Providing native text has a good chance of becoming an interop issue: as some browsers might pick different wording which might break the site's layout on those browsers. Standardizing the text for every language and every option would be a difficult undertaking as well.
   5.3) The restrictions on customization might be too strict for certain developers which means they won't be able to integrate the element into their page without it looking weird.
   5.4) Heuristics that try to prevent bad faith actors might not be tenable long-term as developers keep trying to find ways around them. Having to fight developers raises a red flag around the design of this proposal.

6. In regards to fallback option 1 (to trigger the legacy prompt flow, if the proposed verifications do not pass, e.g. if the PEPC is covered by some other element at the time of the click):
   We went down this path previously with permission.request() and we rejected that idea previously. Ultimately it would be preferrable to fix things at the API level (w3c/geolocation-api#48, whatwg/notifications#108).

Since the PEPC content is controlled by the user agent, and it should have no child elements, the parsing model will not include content or the end tag (similarly to the input element parsing model).

Adding a new void element for HTML parsing can result in new mXSS issues. Consider e.g. https://research.securitum.com/mutation-xss-via-mathml-mutation-dompurify-2-0-17-bypass/ but instead of the form tags you use a <permission> tag before <mglyph>. The onerror script would now execute in browsers where permission is a void element (assuming a sanitizer that allows math).

There might be other similar cases; generally, changes to the HTML parser carry some XSS risk.

I would suggest no changes to the HTML parser here. Require the end tag.

Kick off thread for PEPC discussion.

https://github.com/WICG/PEPC/blob/main/explainer.md#separate-this-into-two-proposals-1-improved-user-intent-signal-and-2-modal-permission-prompts notes

We believe these aspects of the proposal offer the most user utility when bundled. If we only improve the user intent signal with a permission element, we fail to solve for change blindness and accessibility problems for magnification users. If we only introduce modal permission prompts without improving our confidence in user intent and context we increase the level of interruption and disruption in user journeys with blocking modals about which the user may have little or no context for decision making.

It is true that allowing websites to ask for permissions repeatedly requires a stronger signal of user intent.

On the other If we only improve the user intent signal with a permission element, we fail to solve for change blindness and accessibility problems for magnification users. doesn't mean that this needs a PEPC. This is an orthogonal problem.

PEPC should not prescribe a UI for asking users for permission.

What is the purpose of the "onvalidationstatuschange" event? It seems the purpose of the validation is to prevent clickjacking and it's not clear why the site should be informed about it.

If the goal is to help with debugging of invalid states this should be handled locally in the devtools and not exposed to content scripts.

Regret: Given the challenges of permission annoyance and abuse, it is reasonable for user agents to suppress a site's future requests for the same capability when the first request is blocked. That said, our research shows that users can and do change their minds for good reasons. When they change their mind, the site can no longer offer an interface in web content and the user must search for the appropriate user agent surface. Our research shows that users often fail when trying to do so (see example 3).

It seems this problem will get worse for users who would like to revoke a permission. They will be even less likely to be aware of any user agent UI for managing permissions and sites often don't have any incentive to do so.
Even the examples are biased in this sense:


Shouldn't the second button be called "Unshare Location" or show a checked checkbox so users are aware that they can also remove the permissions here?

Per https://w3ctag.github.io/design-principles/#casing-rules, icon-style should be iconstyle.

Per w3ctag/design-principles#280, dismissed and resolved should be dismiss and resolve.

Note that "resolve" in web API design usually refers to promises. I'd suggest "change".

To match other HTML elements, the IDL event handlers onresolve and ondismiss should be on GlobalEventHandlers, not on HTMLPermissionElement.