Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
andypaicu opened this issue Jan 24, 2024 · 1 comment

Comments

@andypaicu
Copy link
Collaborator

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
Copy link
Contributor

marcoscaceres commented Apr 14, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants