Closed jakearchibald closed 5 months ago
If I'm understanding correctly would something like https://github.com/WICG/web-preferences-api/issues/7#issuecomment-1721930664 address this (the change event part at least)
Yeah, but if you introduce a computed value, you probably need two change events, one for the computed value and one for the override value.
I built a POC browser extension that allows changing light/dark mode on a per-site basis by the click of a button. The extension taps into the Web Preferences API for this: read and override the value of navigator.preferences.colorScheme
.
https://github.com/WICG/web-preferences-api/assets/213073/b542edc4-aef9-4417-bd04-c90cd369643b
One of the features of the extension is that the icon in toolbar reflects the active state of the page: if the page is in dark mode, the icon will show a dark icon. If it’s in light mode, the icon will show a light icon.
Right now my implementation isn’t 100% accurate, as I rely on watching the prefers-color-scheme
media query via window.matchMedia('(prefers-color-scheme: dark)').addEventListener('change', e => … })
which doesn’t always trigger.
My OS is in Light Mode.
navigator.preferences.colorScheme
to dark, the MQ listener triggers, so I can update the icon to dark.navigator.preferences.colorScheme
to light, MQ listener triggers, so I can update the icon to dark.navigator.preferences.colorScheme
, the MQ listener DOES NOT trigger because the page basically went from light (override) to light (system).Mutatis mutandis for an OS in Dark Mode where the MQ listener won’t trigger from Dark (system) to Dark (override).
For this reason, a change listener on the PreferenceObject would be feasible, as I also expressed in https://x.com/bramus/status/1733263658543669574 before being pointed to this issue right here.
RE the two values: that’s what I basically do in my extension as well: I get the applied lightOrDark
value from the MQ + I get the navigator.preferences.colorScheme.override
value. By comparing both I know the lightOrDark
value is set by the override or not.
Thanks for following up on this, @lukewarlow!
Apologies for the delay! I've updated the spec and will update the chromium implementation soon.
The override property currently accesses preference override data synchronously. Instead, the spec should detail how the data is synchronised between agents.
When this happens, it feels like there should be some kind of event to inform the developer that one of these values has changed.