Concerns with proposal

[marcoscaceres]

While the Web Preferences API proposal seeks to address genuine issues regarding user preferences on the web, there are several reasons why overriding user preferences might not be a good idea:

• User Autonomy and Trust: Users generally set preferences in their operating systems or browsers for a reason. Overriding these preferences can infringe on user autonomy and erode trust. Users might feel that the website or application is being intrusive or not respecting their choices.
• Accessibility Concerns: Many users set specific preferences for accessibility reasons. Overriding these can make a website less accessible to users with disabilities, potentially leading to a poor user experience or even rendering the website unusable.
• Unintended Side Effects: There is the potential for unintended side effects when overriding certain preferences, especially when the overrides cascade to sub-resources. It can complicate troubleshooting when unexpected behaviors arise.
• Complexity: Introducing such an API adds complexity to the development process. It might also require developers to maintain and consider various overriding scenarios, which could slow down the development process.
• Security Concerns: Allowing sites to override user preferences can potentially open up avenues for malicious websites to exploit. Depending on the exact details of the API, there might be ways for malicious actors to misuse this override capability (e.g., creating a supercookie if the preferences are persistently stored and not cleared with regular browser storage).
• Privacy Concerns: If the override is passed down to sub-resources, there might be potential privacy implications, especially if third-party resources can determine or influence user preferences.
• Consistency Issues: Users expect consistent behavior across websites. If every site can change user preferences, it can lead to a chaotic experience where each site behaves differently.
• Potential for Abuse: Websites might override user preferences for monetization, such as forcing a light mode to display ads better, even if the user prefers a dark mode. This can be detrimental to the user experience.
• Backward Compatibility: Existing websites and tools are designed with the current model in mind. Introducing a new API that changes this fundamental aspect can cause backward compatibility issues.
• Potential Overhead: If not implemented efficiently, constantly checking and applying overrides can introduce performance overhead. For example, it would mean having to reevaluate all media queries.
• User Confusion: Users who set specific preferences and then find those preferences overridden on particular websites might be confused and frustrated. They may not easily understand why a site looks or behaves differently from their expectations.
• Browsers’ Role: Browsers act as a mediator between websites and users. Allowing sites to override user preferences diminishes this role and gives more power to the website, potentially at the user's expense.

While there's merit in providing more flexibility for site developers to improve user experience, any such system should prioritize and respect the choices and rights of the end-user. The current proposal seems to shift too much control away from the user, which can introduce numerous challenges and concerns.

However, site preferences might be a better way to approach this problem (i.e., browsers could just provide these preferences on a per site basis).

That's not to say the use case / issue this proposal seeks to address is not legitimate it. It clearly is. However, it seems to go about trying to fixing it in a way that may end up causing more harm than good.

[lukewarlow]

I'll probably write up a full response to this tomorrow but I just want to respond quickly with a few overall observations.

User Autonomy and Trust, Accessibility Concerns, Consistency Issues, User Confusion

None the of the (valid) concerns raised are at all impacted by this API. The API provides no new ability to ignore user preferences for example. The status quo is that a lot of sites through necessity or ignorance don't use these preferences in their designs. This API provides no new means to ignore the user preference (in fact it does the opposite).

With this API sites could and I expect would make use of all the platform provided nicities with regards to user preferences. While also retaining the ability to offer users a choice to override their global (OS or browser) preference for this specific site.

Obviously a site could override a preference that's not actually based on user choice. But they already can by simply ignoring the preference.

Security Concerns, Privacy Concerns, Potential for Abuse

The points raised in these sections are absolutely valid and I'm very keen to ensure this API lands on the right behaviour especially with regards to sub-resources as to not detriment users in anyway.
Concerns surrounding iframes for example are an open discussion (see #8)

I absolutely don't want this to be used by bad actors, if the WebKit team has any ideas on specific areas that need attention and any potential mitigations I would welcome them to ensure this proposal correclty accounts for them.

Potential Overhead

This should be rather trivial to implement efficiently from my understanding of existing browser code. At least Chromium and WebKit already have dev tools level emulation which don't negatively impact peformance I expect this to be no different.

Backward Compatibility, Complexity

The idea is that this API would massively reduce complexity. A site author could simply make use of all the standard platform affordances (even making use of third party code that does so). And with a minimal API they could implement the common practice of for example a color theme switcher.

Most code other than the specifics for setting the override would be no different should they ever wish to make use of this API or not.

The override would be as opaque as possible to nearly all code (for examples, I expect all iframes would have no knowledge of the override at all instead just appearing to come from the system).

For exactly this reason I don't for see any backwards compatibility issues?

I welcome any details on any that the WebKit team might forsee so we can incorporate it into the design.

Browsers' Role

While raised in my first point I want to reiterate. This API would provide no new mechanisms for author shenanigans beyond that already available to them (e.g. just ignoring a user preference is already the status quo capability). I would frame this API as the browser doing it's role as user agent by providing the means to honour user preference (including the users preference for this site to be different).

[rschristian]

Obviously a site could override a preference that's not actually based on user choice. But they already can by simply ignoring the preference.

I feel that this is key -- there's already nothing that forces sites to adhere to (or even acknowledge) user preferences in the slightest. I can force color schemes on users, animations, contrast levels, etc.

There's nothing in this proposal that alters that status quo in what sites can and cannot present to users. Instead, what it does is consolidate how those preferences are set.

Complexity: Introducing such an API adds complexity to the development process. It might also require developers to maintain and consider various overriding scenarios, which could slow down the development process.

This sounds like a lack of understanding on how sites current address this need?

At the moment, sites are mirroring these preferences and controls themselves to offer more granular control where browsers have failed to provide it. For something like a dark color scheme preference, this usually involves saving the preference to storage (localStorage or a backend, if this is to be persisted for the user across the platform) and DOM manipulation to add a dark class upon an element somewhere.

This is a lot of complexity that each site needs to undergo in order to support this behavior; overriding preferences vastly simplifies things while also encouraging use of these media queries which will aid, not hinder, accessibility.

Potential for Abuse: Websites might override user preferences for monetization, such as forcing a light mode to display ads better, even if the user prefers a dark mode. This can be detrimental to the user experience.

There's nothing that forces a site to provide a dark mode (or any other preference for that matter) as-is. Not quite sure I understand this?

[nt1m]

This should be rather trivial to implement efficiently from my understanding of existing browser code. At least Chromium and WebKit already have dev tools level emulation which don't negatively impact peformance I expect this to be no different.

There would be some overhead in at least triggering style invalidation, and if a website accidentally sets the preference in a hot codepath, they'd effectively be triggering invalidation frequently.

[nt1m]

If the API was built in a way that the UA could deny the override request, I could see one benefit to this API: since websites are going to override the user's preference anyway, might as well provide a proper framework that the user agent can control , then all media queries like prefers-color-scheme/etc. would be reflecting the combination of the site preference + user's final choice.

However even designed with that in mind, there are concerns:

• Fingerprinting, because there would be 2 states for single setting:
  • The user prefers a certain mode & denied the website the permission to request an override
  • The user prefers a certain mode & granted the website the permission to request an override
• User experience: I don't want to see a proliferation of custom light/dark mode toggles on the web from the API (and having to set those individually), I'd much rather have that be a browser preferences' section

Along with these Marcos mentioned above:

• Extra means of storage: any "override" could just be used as a means to store an extra bit of data
• Subresources: if subresources inherit the site override, they could guess some information about the parent site, so some kind of cross origin policy needs to be applied here.
• Performance overhead if not used properly (this is where site preferences done on the browser's side is largely beneficial over this API)

[rschristian]

User experience: I don't want to see a proliferation of custom light/dark mode toggles on the web from the API (and having to set those individually),

I believe most would see this as a huge UX improvement as, unfortunately, not all color schemes are created equal. Even without going into topics such as contrast levels, some users could prefer darker color schemes but dislike the way a particular one is implemented, to the point where it hinders their use -- this is why most sites offer a toggle, as it's critical to both accessibility and UX that users can opt-out on a per site basis.

To give an anecdotal example, I generally prefer dark schemes but find Windows' dark mode to be unusable. Thankfully, I use a browser that lets me freely set this preference away from the OS, yet there are still plenty of sites where I prefer their lighter color schemes to their dark.

A light/dark mode preference cannot reasonably be universal so long as it is up to individual sites, browsers, and OSs to choose how that scheme is implemented. Setting individually therefore gives the user more power, not less. Besides, you will not have to set each site individually if you do not want to; the set preference would be the default value, you'll only set something if you want to stray from your previously selected preference.

If the API was built in a way that the UA could deny the override request,

I don't think it makes sense to frame this as a permission -- it's aiming to replace the (rather large amount of) custom code that each site uses to implement toggles as-is. Code reduction and implementation standardization I believe are the main goals here.

[bramus]

I think not all of the listed concerns are valid ones as websites today already can – and do – ignore user preferences by shipping any color-scheme/animation/contrast they want. Those concerns already are concerns today. Having this API won’t make a difference there.

As for abuse and related concerns: with the proper safeguards in place, websites would not be able to simply change the preference on the fly. This could be done by - for example – only allowing a change after user interaction or by having the UA ask for permission first.

As for privacy: IUC the preference would be stored per origin and won’t inherit down to iframes/resources from different origins. This similar to when the UA would offer a per-site setting. The concerns for both are the same.

I do see @nt1m’s concern where authors would be able to track if a user allowed or denied permissions. Maybe that could be another UA option where users can say they don’t want to allow customization by sites and – in that case – the UA would report no support at all for the API?

Taking a step back: the big benefit that this API brings is that authors can more nicely build their Dark Mode Toggles without needing to duplicate a bunch of CSS nor having to resort to blocking JS to keep the UI in sync with the setting. The reality is that authors already create those toggle buttons today – mostly poorly done – and sites are riddled with these buttons and options. For example: GitHub, StackOverflow, Apple Developer, Twitter, … all have options in their preferences or sport toggle buttons.

For more details about these benefits to authors: I’ve written about this problem space before, on my personal blog: https://www.bram.us/2022/05/25/dark-mode-toggles-should-be-a-browser-feature/

[lukewarlow]

On the specifics of the user activation and permissions both of these were questions I had early on and on the basis that this API doesn't allow site authors to do ANYTHING newly bad from a user experience point of view I and Tab concluded that it probably isn't needed. I'm more than happy to rethink that position though.

[nt1m]

To give an anecdotal example, I generally prefer dark schemes but find Windows' dark mode to be unusable. Thankfully, I use a browser that lets me freely set this preference away from the OS, yet there are still plenty of sites where I prefer their lighter color schemes to their dark.
A light/dark mode preference cannot reasonably be universal so long as it is up to individual sites, browsers, and OSs to choose how that scheme is implemented. Setting individually therefore gives the user more power, not less. Besides, you will not have to set each site individually if you do not want to; the set preference would be the default value, you'll only set something if you want to stray from your previously selected preference.

Yes, I think a solution to this problem is a toggle at the browser level (potentially with site-specific settings), not the website level.

Taking a step back: the big benefit that this API brings is that authors can more nicely build their Dark Mode Toggles without needing to duplicate a bunch of CSS nor having to resort to blocking JS to keep the UI in sync with the setting. The reality is that authors already create those toggle buttons today – mostly poorly done – and sites are riddled with these buttons and options. For example: GitHub, StackOverflow, Apple Developer, Twitter, … all have options in their preferences or sport toggle buttons.

I am well aware of the challenges this proposal is trying to solve. However, I do not think this API is the right approach. User preferences should be controlled by the browser, not the site. Browsers could provide per-site settings, and an API among the lines of navigator.showSiteSettings() (name to be bikeshed) could be used to show them. Something like this would address some of the concerns I mentioned at least:

• you can't accidentally set an override in a hot codepath (causing perf issues), the API would trigger some browser UI to show up.
• you don't risk the websites misimplementing the default behavior (which is defaulting to system/browser global setting), hence always honoring user preference, and not the site's
• this API would still work if the user has storage disabled (I assume sites would need to store overrides somehow with the current proposal)
• overriding and using the default browser/system setting aren't distinct things anymore from the websites POV.

[lukewarlow]

this API would still work if the user has storage disabled (I assume sites would need to store overrides somehow with the current proposal)

The idea is this state would be browser handled.
So navigator.preferences.colorScheme = 'dark' would persist on page reload without the site needing to use any other storage mechanism. I imagine it'd be stored in the same way the browser stores something like a permission state.
So it would be clearable while clearing site settings but wouldn't get removed by mechanisms such as for example Safari's removal of data after 7 days of non use (apologies if the specifics are wrong but the gist I hope is clear). It also wouldn't be broken by disabling of storage (I wasn't aware that was a capability but this API wouldn't be affected by it)

you don't risk the websites misimplementing the default behavior (which is defaulting to system/browser global setting), hence always honoring user preference, and not the site's

The default is that these attributes are all null and as such default to the OS/browser default. Only once they set an override through this API would it be overridden. So I'm unclear how they could 'misimplement' this?

[rschristian]

Yes, I think a solution to this problem is a toggle at the browser level (potentially with site-specific settings), not the website level.

I think the point here is that OS and browser-level toggles are not at all sufficient; the problem won't be addressed without site-specific settings. Therefore "potentially" feels like strange language to use as without it the problem remains all the same.

I'm happy to be wrong here, but it also feels like delving into browser settings to set preferences on a per-site basis will be quite a poor UX. Nothing else really comes close to that today so I doubt many users will be comfortable in doing it. Compare that to (say) Astro's Docs, in which there's a clear and obvious toggle at the top of the page. I have little confidence browser settings will improve upon this UX.

[marcoscaceres]

Right, but you are making our point @rschristian. If you are arguing that browsers can't do setting right (which we obviously don't agree with), then can we really expect sites to adequately provide good settings UIs... and then multiply that problem at web scale. Wouldn't it just make sense to just fix it at the source? (i.e., browser to provide better per-site controls and settings?)

We do this already in Safari, for instance:

(notice benefits like sync across devices, etc.)

Again, we acknowledge that there is, in certain cases, a need for users to override settings on a per site basis for a variety of reasons - and strongly linked to accessibility. This is normal and has been around for years (e.g., permissions, page zoom, etc.). But we fundamentally disagree that sites overriding user preferences is an ever a good thing. If this became a hindrance, browsers would ultimately just re-override anything the site is overriding.

Providing an API should always be the last thing we do on the web for anything... it means that we've exhausted all other possible avenues of how to tackle a particular problem. We don't think we've reached that point with the use case / issue outlined by this proposal, which is why we are opposed to it (in addition to all the additional unintended side effects I mentioned above).

[marcoscaceres]

Just for parity, Chrome's per site settings are not particularly difficult to get to. It's two clicks.

One:

and two:

[rschristian]

Right, but you are making our point @rschristian. If you are arguing that browsers can't do setting right (which we obviously don't agree with), then can we really expect sites to adequately provide good settings UIs

I don't think I am.

Sites already provide far, far better UIs for this style of configuration and it's something users have grown very accustomed to over the years. A toggle button on the page itself is objectively better and more available than requiring users delve into their browser settings with a few very specific clicks, as your examples show. I'm a web dev and even I forget how to quickly get to those settings some days; not in a million years would I expect my mother to be able to find that, but what she can do is find the sun/moon icon at the top or bottom of a page.

Unless an implementation of this comes with a massive revamp in the way all browsers display this information and make it accessible to the end user, I can't see what you suggest as anything other than a massive regression in user control over their browsing experience. Any amount of burying a setting will reduce the number of users who will make use of it, this is true of any and every UI.

But we fundamentally disagree that sites overriding user preferences is an ever a good thing

Would you be able to address how this differs from the status quo in any way? If someone prefers dark color schemes, I can still serve them content with background-color: white today. I don't need to override user preferences as I'm free to disregard it completely.

I honestly cannot understand your position here, as unless browsers figure out a way to enforce user preferences upon every site, sites will always be free to utterly ignore, if not override, user preferences. Is that a legitimate goal perhaps?

[nt1m]

The default is that these attributes are all null and as such default to the OS/browser default. Only once they set an override through this API would it be overridden. So I'm unclear how they could 'misimplement' this?

The override can be set anytime right? Including on DOMContentLoaded? AFAIK I don't see any user gesture requirement to set the overrides.

[romainmenke]

One scenario to keep in mind is when a website is completely rebuild.

An old version of a website might have implemented this API and users might have set various overrides. These overrides would persist even after a website's code is changed completely.

The new version of the website might not have implemented this API, leaving users stuck with settings they can't easily access.

Clearing site data to escape this issue isn't ideal because it isn't what the user wants to do. They do not want to clear all site data, they only want to delete an override to a preference.

[lukewarlow]

The new version of the website might not have implemented this API, leaving users stuck with settings they can't easily access.

One possible solution to this is to have browser UI for this that this API allows a site access to and control of. But yes that's definitely a problem worth keeping in mind.

[bramus]

The new version of the website might not have implemented this API, leaving users stuck with settings they can't easily access.

I don’t think this API and site-preferences surfaced through the UA should be mutually exclusive. Both features go hand in hand, the one augmenting the other.

[romainmenke]

I don’t think this API and site-preferences surfaced through the UA should be mutually exclusive. Both features go hand in hand, the one augmenting the other.

I agree :)

The case I described above would only be an issue if there aren't any site-preferences surfaced through the UA.

[lukewarlow]

An initial draft at redesigning the API based on feedback here and during the CSSWG meeting, along with clarifiying certain interactions with other features is complete I'd be keen to hear if this addresses any concerns raised.

TLDR:

• API using an async requestOverride function, to give UA greater control over the process. UA can decide to reject the request based on a UA defined algorithm.

(Apologies if the spec is written awfully this is my first attempt at writing normatively so feel free to make any issues ripping the writing apart 😂 . Hopefully the general intention is clear though.)

[lukewarlow]

I've also subsequently removed the ability to set a "no-preference" override. This makes the overrides opt-in only rather than allowing sites to opt the user out leading to poor user experience. This is especially important when considering UA behaviours these preferences can control (e.g reduced motion disabling smooth scrolling)

[marcoscaceres]

Upon further discussion we still believe that this is not the correct solution to address this set of use case (although we acknowledge the validity of the use case). We believe perhaps something like custom media queries and using local storage could address these use case.

Thus, our position remains "opposed" to this proposal.

[lukewarlow]

I respect that we have a fundamental disagreement here and I won't be able to change your mind. But I just want to explicitly say Custom Media Queries are NOT the solution and this is explicitly called out in the proposal.

I'm going to go ahead and close this issue now. If anyone would like to raise any specific concerns feel free to open new issues with concrete examples and I'd be happy to work towards a solution.