Summary of feedback from @marcoscaceres on https://github.com/WICG/PEPC/pull/7

[andypaicu]

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 (Require user activation to use API w3c/geolocation#48, Require user gesture for notification permission request whatwg/notifications#108).

[marcoscaceres]

General webKit position on PEPC WebKit/standards-positions#270