search

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

Remove PreferenceResult? #5

Closed tabatkins closed 1 year ago

tabatkins commented 1 year ago

(This likely depends on #4.)

I suspect we can remove PreferenceResult entirely and simplify the API somewhat. Right now PreferenceResult does three separate things:

  1. Holds the value of the preference.
  2. Holds a bool for whether the value comes from an override or is the user's native preference.
  3. Is an EventTarget for the "change" event.

(3) likely should be done more generally, on MediaList - if you want to listen for changes to an MQ, you almost certainly want those changes regardless of whether they come from an override or the user's pref changing. (I was certain we already had this API - a "change" event on MediaList - but it looks like we don't. We should fix that.)

(2) seems like it could reasonably live in PreferenceSupportData instead. You won't often need this data, so putting it behind a method call seems just fine.

And with those changes we'd reduce PreferenceResult to just the value string, which means we could collapse it down to just a string and eliminate the interface entirely.

tabatkins commented 1 year ago

(I was certain we already had this API - a "change" event on MediaList - but it looks like we don't. We should fix that.)

Duh, of course we do, it's just in CSSOM-View for some reason: https://drafts.csswg.org/cssom-view-1/#mediaquerylist

It doesn't let you directly ask "what's the value of this MQ", but you can ask "does this MQ match this value", and you can set up several to figure out the value of any particular one. (Which is good in general - MQs aren't defined to have "a value", but rather just to match a query; a single MQ can match multiple values at once. Preference queries might be different, and could possibly be considered to have a single particular value, but I don't think we should lock them to this meaning if we don't have to.)

lukewarlow commented 1 year ago

I think this makes perfect sense. I'll work on a revision that addresses this and your other raised issues.

For now I'll move the "Should we include a new API to get the "computed" value of a preference?" into a Question at the bottom as I'm unsure how best to address that. getSupportedData doesn't necessarily feel right but also the ergonomics of Media Query List change isn't necessarily perfect either.