search

WICG / web-preferences-api

The Web Preference API aims to provide a way for sites to override the value for a given user preference (e.g. color-scheme preference) in a way that fully integrates with existing Web APIs.
https://wicg.github.io/web-preferences-api/
Other
41 stars 2 forks source link

The API design should allow for more UA involvment #27

Closed FremyCompany closed 9 months ago

FremyCompany commented 9 months ago

During the discussion presenting this feature in the CSS Working Group at TPAC this year, a few concerns were raised, notably about the role the User Agents should have (or not have) in this process.

To be truly useful, the changes requested by the users should be consistently applied by both the website and the browser in its handling of the website. (see #24)

However, letting websites unilaterally modify user preferences for their site is usually not considered acceptable, especially when it pertains to accessibility requirements like reduced motion, or forced colors.. (see #15 #26 etc...)

That said, it seems reasonable for websites that are specifically designed to desire the user to trust them to do the right thing for them, and let them run in an environment with modified user settings.

There is still some debate about how much UA should be involved in this settings negotiations, but certainly some UAs did not want persistent settings not to be visibly surfaced and shepherded by them. (see #16)

As a starting point, I believe the API should at least make it possible for UAs to step into that role. This requires the API to be updated from a synchronous to an asynchronous API, which would potentially let the User Agent display permission dialogs, and reject change requests on behalf of the user.

Per site settings are already a concept in most browsers, including Chrome (see e.g. chrome://settings/content/siteDetails?site=https://.../)

UAs could of course decide not to show a permission dialog and show a notification only (like for fullscreen), and decide how much UI surface they devote to the issue of fixing incorrectly remembered (only allow to clear that persistence via clearing cookies, or providing custom controls that show the current value of the overrides to the user, such that these can be changed directly).

Regardless of the details, the API should cater to all these possibilities. As a strawman, I propose the following:

navigator
  .preferences
    .reducedMotion
      .requestOverrideTo(value: string): Promise

where the Promise would resolve to value if the change succeeds, and would (presumably) reject otherwise.

Letting the browser be in the loop here reduces concerns about the security and accessibility aspects of the proposal, in my opinion.

(One concern is that websites can be updated to no longer provide the toggle for changing the settings, and users might still want to reset them to the default if they had set a custom values for a previous version of the site)

lukewarlow commented 9 months ago

Yep the API originally was async functions and I'm happy to revert to that idea to satisfy certain concerns.

FremyCompany commented 9 months ago

As food for thought, I would also maybe suggest a new site Permission to enable modifying these user settings on their behalf, that would enable to UAs to skip their intermediary role. This could be a later update if website authors feel the meddling too much of a pain.

lukewarlow commented 9 months ago

@FremyCompany please let me know if the updates spec is satisfactory to address the issues raised. Thanks for the feedback!

As per https://github.com/WICG/web-preferences-api/issues/28#issue-1899144848 I also want to make sure that we really need a permission grant. And what the alternative would look like in terms of UA "interference". I really do think developers will be put off by something where the browser unnecessarily prompts the user for something where they otherwise wouldn't be.

FremyCompany commented 9 months ago

Looks good to me. One other thing that occurred to me is that "getSupported()" might not be required now that each entry is an object. Iterating the keys of navigator.preferences should yield them all, and the valid values for an override could be exposed on the objects as a "validValues" property.

Regarding the permission, I am not sure whether the fullScreen behavior of making the change then asking for forgiveness with a pop-up isn't better than a preliminary permission, in this case, but I guess this should be a different issue with input from more people?

lukewarlow commented 9 months ago

Closing now that the API uses a promise based request function.