Web Preferences API

[lukewarlow]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Web Preferences API
• Specification or proposal URL (if available): https://wicg.github.io/web-preferences-api/
• Explainer URL (if available): https://github.com/WICG/web-preferences-api/blob/main/README.md

Other information

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.

Early days for the proposal but I want to reach out early and get feedback.

[lukewarlow]

Gentle ping on this, interested in whether Mozilla think this is a good idea and gaining feedback. An experimental implementation (without persistence on browser restart) is available inside of Chromium if you wanted to give it a go.

[zcorpan]

I can see that this would be useful at least for color-scheme (light mode/dark mode) since it's common to have a site-specific toggle for that, and being able to use themes and components developed by someone else using prefers-color-scheme MQ, seems nice I think.

Is there demand to override any other preference?

[lukewarlow]

I have an ongoing issue WICG/web-preferences-api#29 where I leave examples of use cases. I've found a number where they would benefit from reduced motion and contrast on top of colour scheme

[bgrins]

I do think the color scheme feature would be useful. For example, I heard from the MDN team that being able to just use a <picture> with two <source>s to show a corresponding light or dark screenshot would be an improvement to what they do today. So, like @zcorpan, I'm positive on the use case. Although I can certainly understand concerns about allowing sites to override the system & UA settings.

A point on naming - "Web Preferences" is quite broad and I think implies one of the non-goals is in scope:

Provide a way for sites to store arbitrary site-specific preferences -- local storage or other storage APIs should be used instead

AFAICT the use cases you have in mind are focused on media queries - have you considered renaming (and if necessary, updating the design) to focus specifically on media query preferences?

[lukewarlow]

I did consider alternative names that was just the best I could think of. I'm open to any and all suggestions for names.

The API is very much focused on the user preference media queries from CSS. But it would also apply to other functionality such as the "used colour scheme" concept, the client hint headers, and potentially more. But they're all very closely linked.

[lukewarlow]

Although I can certainly understand concerns about allowing sites to override the system & UA settings.

Yeah I understand the sentiment and I'm open to any feedback on how this could be addressed. I think ultimately my response comes back to, people can just ignore these preferences today. So this API introduces almost no novel capabilities (aside from the obvious). I currently don't allow "no-preference" as an override choice but I'm not sold that that's actually solving anything and Tab was keen to push back on removing functionality to address what isn't a real issue.

I'd be curious for your thoughts there. (WICG/web-preferences-api#30)

Feel free to raise an issue for any other feedback, ideas or concerns you might have.

[bgrins]

FWIW, I do think tightly scoping not just the name but also the overall design to media queries would be make sense. I don't know the use cases for overriding client hint headers, but perhaps those would end up being differently shaped solutions for different use cases.

For example, if this was tightly focused on media queries / color scheme use case then perhaps it would make sense for the surface area would be smaller & exposed as a pair to matchMedia, like overrideMedia(mediaQueryString, value) which acts like requestOverride (clears the existing if it's null, returns a promise, throws if it's an invalid value or you try to override an unsupported media query). There may be other good reasons not to design it this way specifically, but I think it may be useful to consider how to approach it if it was focused only on media queries (which AIUI would cover the most concrete use cases).

[bgrins]

Yeah I understand the sentiment and I'm open to any feedback on how this could be addressed. I think ultimately my response comes back to, people can just ignore these preferences today. So this API introduces almost no novel capabilities (aside from the obvious).

Offering the site the ability to override a media query (and allowing the UA to override the override based on heuristics and user preferences) seems fine to me. I can see the argument to instead hoist the UI up to browser chrome but practically speaking having in-page UI for choosing a theme seems natural and is already widely deployed. There are edge cases to consider (e.g. different pages on the same site where a user prefers different themes, or sites that currently has an override having pages which don’t offer a theme switcher), but AFAICT those would need to be dealt with regardless of where the UI lives.

I currently don't allow "no-preference" as an override choice but I'm not sold that that's actually solving anything and Tab was keen to push back on removing functionality to address what isn't a real issue. I'd be curious for your thoughts there.

I haven’t followed closely enough to understand when someone would use no-preference vs simply clearing the override, or why no-preference is specifically a problem compared with other overrides.

[zcorpan]

color-scheme is propagated to cross-origin iframes (see w3c/csswg-drafts#4772) so this would be a side channel from parent to child. (Other side channels exist already, like iframe's width.)

[zcorpan]

A declarative way to override might be good to avoid a Flash of Wrong Color-Scheme during page load / navigation.

[lukewarlow]

The preferences are designed to be persistent. So once set the browser has access to them on page load

[lukewarlow]

Wrt iframes there's an open question on exact behaviour. The intention is to "leak" it if there's already a communication channel and to isolate it if there's not. The overrides also won't be leaked so the embedded site can't use the API to know if it's an override or not.

Part of me even wonders if we should just block the API inside of iframes entirely but that needs further discussion.

[lukewarlow]

I don't know the use cases for overriding client hint headers, but perhaps those would end up being differently shaped solutions for different use cases.

So the headers in question reflect the preference media queries to the server so they're quite tightly coupled to media queries.

Another API is something like the save data API which could be interacted with based on the reducedData preference (if that was to be included).

As for your API design question. I'm open to suggestions one thing with the current design is that it doubles as feature detection. You can detect that not only is the API itself supported but also the exact preferences.

[zcorpan]

The preferences are designed to be persistent.

Ah, I had missed that. That means it's a persistent storage mechanism (but can only store as a small number of bits).

[lukewarlow]

Yeah I'm hoping it can bypass some of the we'll clear your storage after 7 days mechanics because as you say it's a limited width storage mechanism. But ultimately that'd be up to the UA to decide.

I'd make sure that they're cleared when you clear site data so they're not some super storage that you can only clear with JS.