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

should setting overrides be supported only after user actions? #2

Closed Kilian closed 9 months ago

Kilian commented 10 months ago

Certain APIs, like the eye dropper API, will only work after a user action (like clicking a button). It seems like this API would also benefit from that.

lukewarlow commented 10 months ago

I would tend to agree the only issue I can see with that is it prevents automatic syncing of settings from other devices, on page load or later?

lukewarlow commented 10 months ago

Not sure this warrants a permission but potentially instead of requiring user activation always it requires it the first time and a permission grant and can be called without user activation from then on?

tabatkins commented 10 months ago

I don't see why we would want to put any restriction on here. Authors can always just... not use the related MQs, and thus ignore whatever the user preference is. So being restricted from overriding a user pref doesn't actually prevent them doing anything.

jimmyfrasche commented 10 months ago

Say you could do one set of overrides without user interaction but after that you required user interaction per setting. That would let you bulk load settings from a cookie or whatever on start up and respond to preference updates. Would that be enough to make it indistinguishable from the preferences changing at the browser/OS level so that passing the settings down through iframes etc do not count as passing information?

tabatkins commented 10 months ago

No, the user interaction bit can come from anything; the user clicking somewhere in the page can't constitute permission to talk to a cross-origin iframe somewhere on the page.

lukewarlow commented 9 months ago

The spec has been updated to require user activation on first call (requesting permission) to the new requestOverride function. After that it doesn't require user activation however.