You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
By exposing the original + the overridden value, one can single out users who have overridden the preference.
You can already determine that based on the current API design? navigator.preferences.colorScheme.override will be null if it's the original value or set if its overridden.
While you can't determine the OS value at the same time as the override you can just clear the override read the value and set the override again. I don't think it's introducing anything novel wrt fingerprinting?
Having said all that I think my main question is what are the use cases? Are they valid enough for the potentially extra complexity (especially if we have to track changes to both)?
Copied from:WICG/web-preferences-api#38
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).
cc @kizu
The text was updated successfully, but these errors were encountered: