WICG / web-preferences-api

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.
https://wicg.github.io/web-preferences-api/
Other
41 stars 2 forks source link

Override change event #33

Closed jakearchibald closed 5 months ago

jakearchibald commented 7 months ago

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.

lukewarlow commented 7 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)

jakearchibald commented 7 months ago

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.

bramus commented 7 months ago

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.

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.

bramus commented 5 months ago

Thanks for following up on this, @lukewarlow!

lukewarlow commented 5 months ago

Apologies for the delay! I've updated the spec and will update the chromium implementation soon.