- From: Bramus! via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 Sep 2023 11:20:53 +0000
- To: public-css-archive@w3.org
Last year I wrote about this problem space and why authors need this [on my blog](https://www.bram.us/2022/05/25/dark-mode-toggles-should-be-a-browser-feature/). To accompany that article, I also built [an interactive prototype](https://codepen.io/bramus/full/yLvbgxL) that shows how it would work: - Use one of the dropdowns to change the OS / Browser / Site level setting. These settings work as a waterfall. - Use the links in the page itself to change the Site level setting _(these would call the proposed API)_ - Use the button in the UA chrome itself to change the Site level setting. Try the prototype here: https://codepen.io/bramus/full/yLvbgxL Notice how everything is nicely in sync: - Setting the value at the site level from within the page gets reflected in the UA’s settings _(note how the button next to the address bar changes)_. - Changing the Site’s level via the UA-provided botton is immediately reflected on the page in the MQ. _(This UA provided button could be a setting pane somewhere. I added it to this prominent place for demonstration purposes)_ By syncing this setting to the UA’s per-site settings – similiar to how you control access to camera, geolocation, etc – it can persist those settings in your profile and sync it across devices. As noted in https://github.com/WICG/web-preferences-api/issues/16#issuecomment-1710794442, changing the value from within script should have the proper safeguards. E.g. the UA could ask for confirmation the first time a site wants to change the value, similar to how sharing your geolocation works. -- GitHub Notification of comment by bramus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6517#issuecomment-1721109107 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 15 September 2023 11:20:57 UTC