Web Preferences API

[lukewarlow]

WebKittens

No response

Title of the spec

Web Preferences API

URL to the spec

https://wicg.github.io/web-preferences-api/

URL to the spec's repository

https://github.com/WICG/web-preferences-api

Issue Tracker URL

No response

Explainer URL

https://github.com/WICG/web-preferences-api/blob/main/README.md

TAG Design Review URL

No response

Mozilla standards-positions issue URL

https://github.com/mozilla/standards-positions/issues/879

WebKit Bugzilla URL

No response

Radar URL

No response

Description

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.

[marcoscaceres]

We are discussing this internally, but we already identified many issues that we will report on the incubation's repo.

We feel overriding preferences via javascript might not be the right approach, and perhaps per-site user preferences might be an alternative way of dealing with this.

Unless anyone objects within a week or so, we will make mark this as "opposed".

[bramus]

I don’t think an API to override things and per-site user preferences should be mutually exclusive. Both can co-exist.

The addition of this API would allow authors to properly implement Dark Mode Toggle buttons – a feature available on many websites and in various (broken) flavours. Last year I have written about why we need this on my personal blog: https://www.bram.us/2022/05/25/dark-mode-toggles-should-be-a-browser-feature/

With the proper safeguarding – e.g. allowing changes only after user interaction, or by having the UA ask for confirmation before allowing a change via this API – abuse of this API can be prevented.

On a side note: making a judgement (a week from) now on such a new API - one that is still being incubated – feels pretty rushed to me. There hasn’t been a proper discussion nor an opportunity to address any concerns, yet the door already seems closed.

[lukewarlow]

Posted on your repo issue but cross posting here too.

An initial draft at redesigning the API based on feedback here and during the CSSWG meeting, along with clarifying 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.

[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.