- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Jul 2024 16:30:56 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[mediaqueries-5] Script control of (prefers-*) queries`, and agreed to the following: * `RESOLVED: Put this proposal into css-mediaqueries-5` * `RESOLVED: Add lwarlow as an editor for mediaqueries-5` <details><summary>The full IRC log of that discussion</summary> <flackr> TabAtkins: we've discussed this before. For a quick recap, there are many cases for e.g. light mode or dark mode on an individual site that can be distinct from OS preference<br> <flackr> TabAtkins: right now, you have to manually store some bit in a cookie, doing styling based on that info with JS, possibly flashing the wrong style of content before that JS runs, in general it's relatively awkward to have something possibly depend on a media query or script info<br> <JaseW> Example: https://expressjs.com/ does this (Flash of unstyled content/theme while it figures out what you want)<br> <flackr> TabAtkins: this proposal is to allow a site to override what the OS / browser says the value of a MQ is, and a persistence mechanism to keep it until the site data is cleared or removed<br> <flackr> TabAtkins: the author can always ignore the MQ and do what they want, it just allows them to rely on the MQ and optionally override it without separate code paths<br> <flackr> TabAtkins: This seems to have overall support. Would we like to adopt this into a csswg deliverable?<br> <flackr> TabAtkins: Possibly css, possibly webapps. Given the tight connection to MQ likely css.<br> <florian> q+<br> <flackr> TabAtkins: It would likely go in css-media-queries-5<br> <astearns> ack florian<br> <lwarlow> q+<br> <flackr> florian: Based on how you described it, I'm supportive. In the issue some comments seem contradictory. E.g. "this api is to override the underlying perference affecting all the things"<br> <flackr> florian: does this affect the underlying thing as well as the MQ's? This seems confusing<br> <astearns> ack lwarlow<br> <ntim> p+<br> <flackr> lwarlow: as spec'd, the preference applies to the MQ, is used as calc for used color-scheme, used to override the user preference MQ client hints, that's the 3 main things. It is largely the MQ.<br> <flackr> lwarlow: the used color-scheme seems reasonable as part of that<br> <flackr> florian: is this different from what TabAtkins said?<br> <khush> q+<br> <flackr> lwarlow: yes, slightly different. it is only affecting the MQ and not changing anything you can't ignore already<br> <flackr> TabAtkins: right, keeps things consistent across these apis<br> <astearns> ack khush<br> <flackr> khush: 2 questions. Are you thinking of exposing this for all MQ's, or an allowlist that is expected to be overridden? E.g. maybe prefers-reduce-motion doesn't make sense?<br> <flackr> khush: Are there cases for closed shadow roots or UA shadow dom where authors can now override things they couldn't before?<br> <flackr> lwarlow: The list of MQ's supported are the 5 pref ones, color-scheme, contrast, reduce-motion, reduce-transparency and reduce-data<br> <flackr> lwarlow: I've done some research to sites in the wild. Reduce motion comes up often, so for the same reasons as color-scheme i think this makes sense<br> <JaseW> q+<br> <flackr> lwarlow: to the second point, yes currently there could be user-agent styles using MQ's that would be affected. Off the top of my head I'm not aware of any though.<br> <flackr> lwarlow: I think this fits into the premise of the API but it is a slightly new capability<br> <flackr> TabAtkins: I think it's entirely a good thing that this works, to keep things consistent to having the MQ pref set in the browser<br> <flackr> TabAtkins: right now, script controlled functionality doesn't do this resulting in inconsistent behavior<br> <flackr> TabAtkins: this makes everything behave as expected<br> <flackr> khush: sounds reasonable<br> <astearns> ack JaseW<br> <flackr> JaseW: A question for implementers, how would you feel if a site requests an override for color-scheme or reduce-motion? Would you expect this to trigger a permission prompt? We've already mentioned web devs can ignore, so how do we feel about this?<br> <flackr> JaseW: do you expect some UI alongside this? e.g. allowing users to change the value through the browser<br> <flackr> TabAtkins: This has been discussed. Because it's no additional functionality, it doesn't need a permission prompt<br> <flackr> TabAtkins: for resetting something, this should be tied to site data. So you can clear site data and clear these prefs<br> <flackr> TabAtkins: UA's could offer more granular controls but it would at least be recommended to reset with site data<br> <ntim> q+<br> <astearns> ack ntim<br> <flackr> ntim: I'm concerned that this is persistent. Let's say the site changes owner, the override stays on that domain. This seems wrong. Whereas persisted by cookies the new site wouldn't use the cookie<br> <lwarlow> q+<br> <flackr> ntim: The user doesn't have an obvious way to reset this<br> <flackr> TabAtkins: worst case a user can reset site data, but otherwise hopefully the web dev would clear this<br> <JaseW> q+<br> <astearns> ack lwarlow<br> <flackr> lwarlow: you can already design your site to ignore the user pref<br> <flackr> lwarlow: the idea is you'd probably have a way in the UA to clear these independent of clearing cookies but on the spec side wouldn't be required to have<br> <flackr> lwarlow: the fact that it's persistent is a powerful part of this API, to avoid a flash of incorrectly styled content, JS at every load to restore, etc<br> <flackr> lwarlow: I see the issue, but given good browser UI and existing problem, it doesn't seem too concerning<br> <khush> q+<br> <astearns> ack JaseW<br> <khush> q-<br> <flackr> JaseW: is there not already a concept of per-site settings based on the origin rather than cookies?<br> <flackr> JaseW: seems like this could be part of that<br> <ntim> q+<br> <astearns> ack ntim<br> <flackr> ntim: does that mean the api will need to be async? if the browser can provide UI to disable / override it<br> <flackr> lwarlow: the api is designed so the request override is an async function<br> <flackr> lwarlow: i don't think requesting the override generally requires intervnetion but it could be<br> <flackr> q+<br> <flackr> astearns: are there many open issues on the repo to be addressed?<br> <khush> q+<br> <flackr> lwarlow: there's one or two, how this interfaces with third party iframes. I think the answers already exist in various specs and just need to relay that information<br> <flackr> lwarlow: mainly ensuring this doesn't introduce a new communication channel<br> <flackr> lwarlow: also does it make sense to have all of these supported? based on research it seems the answer is yes<br> <astearns> ack flackr<br> <TabAtkins> flackr: I think it would be good if hte UA was allowed to set as well as clear them<br> <JaseW> q+<br> <TabAtkins> flackr: UA could decide it wants a darkmode per-site toggle, could be useful to do<br> <flackr> lwarlow: i agree, this is the intent that it coudl be set by the UA<br> <astearns> ack khush<br> <flackr> khush: was going to say the same thing as flackr, it seems better if this were browser ui, then we don't have to force each website to implmement a pattern of adding a button<br> <miriam> q+<br> <flackr> khush: if this were to exist would we still want this?<br> <flackr> lwarlow: if that existed, it'd be great, but i still think at least color-scheme and possibly others you still have a use case where you want to sync values across accounts (e.g. log in on a diff browser), and even aside from this there are enough sites in the wild that have existing dark mode toggles that would be nice to integrate<br> <flackr> lwarlow: with just the browser ui, some sites would probably still have their own setting<br> <keithamus> q+<br> <flackr> flackr: I agree<br> <astearns> ack JaseW<br> <astearns> ack miriam<br> <flackr> miriam: I also support this view. It would be amazing to have browser UI for this, but sites will still want it as part of their interface<br> <astearns> ack keithamus<br> <ntim> q+<br> <flackr> keithamus: light and dark are fine, but for artistic styles there's no way to enumerate these to the UA other than inferred from the stylesheets<br> <flackr> keithamus: there's an idea to add a custom-ident, would the API allow overriding this?<br> <flackr> lwarlow: in its current form no, but it could be extended to set this<br> <flackr> lwarlow: you'd basically be able to build github's preferences, high contrast, dark mode, etc<br> <khush> that's a good point.<br> <astearns> ack ntim<br> <flackr> ntim: I'd have a concern about custom idents if the site doesn't have a way to enumerate them<br> <flackr> ntim: if we were to show browser ui, we should be able to enumerate what's supported vs what's not<br> <ydaniv> q+<br> <flackr> ntim: i think this should be limited to a certain set of MQs. I don't think the site should be able to override forced colors for example, or other AX related queries<br> <flackr> TabAtkins: right, only the prefers ones rather than ones that are ignorable / preference<br> <astearns> ack ydaniv<br> <flackr> ydaniv: speaking for a design tool, it'd be good to have the API so that you could check how your site looks with different schemes / MQ values<br> <flackr> astearns: I'm hearing concerns for particular bits of this API, which MQs it should apply to what values it supports, this can be hashed out in our draft but it sounds like we have rough consensus to add it to mq 5<br> <flackr> astearns: any objections to putting this in MQ5?<br> <flackr> RESOLVED: Put this proposal into css-mediaqueries-5<br> <flackr> TabAtkins: can we add lwarlow as an editor?<br> <flackr> lwarlow: I'm happy to<br> <flackr> RESOLVED: Add lwarlow as an editor for mediaqueries-5<br> <flackr> astearns: can you migrate issues over as needed?<br> <flackr> lwarlow: yes, will do<br> <ChrisL> Yay another NJTF editor!<br> <flackr> astearns: please open issues about custom idents, what MQs this applies to and the issues raised here<br> <ChrisL> * Not Just Tab & Fantasai<br> <TabAtkins> +1 to njtf<br> <flackr> astearns: anything more on this?<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6517#issuecomment-2220975121 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 10 July 2024 16:30:57 UTC