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.
There are legit cases when you'd want to override the value that is used everywhere, but then still be able to differentiate how things look/behave based both on the original value, and on the override. See https://blog.kizu.dev/querying-the-color-scheme/#not-the-user-preference, for example — it is very similar to what we'll have with the web preferences.
With the way things are specified right now, we could do it in a hacky way: clear the override, read the value, restore the override, but that feels very cumbersome and inconvenient.
It would be great if we could get the original value natively (and also monitor it similar to matchMedia maybe).
(Copying from a mastodon thread with some rewording — https://front-end.social/@kizu/113160248251763608)
There are legit cases when you'd want to override the value that is used everywhere, but then still be able to differentiate how things look/behave based both on the original value, and on the override. See https://blog.kizu.dev/querying-the-color-scheme/#not-the-user-preference, for example — it is very similar to what we'll have with the web preferences.
With the way things are specified right now, we could do it in a hacky way: clear the override, read the value, restore the override, but that feels very cumbersome and inconvenient.
It would be great if we could get the original value natively (and also monitor it similar to
matchMediamaybe).