- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 21 Jan 2026 17:27:07 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[mediaqueries] Effect of <meta name=color-scheme> on the (prefers-color-scheme) MQ`, and agreed to the following: * `RESOLVED: close no change` <details><summary>The full IRC log of that discussion</summary> <bramus> scribe+<br> <bramus> TabAtkins: we had a discussion about this in the past<br> <bramus> … the meta=color-scheme element in html sets the value of color-scheme on the root<br> <lwarlow> q+<br> <florian> q+<br> <bramus> … this affects what color we resolve to (light and ark mode) but does not adjust the result of the MW<br> <bramus> … this means you cannot use this attr as a theming switch<br> <bramus> … there is no safe/not annoying way to do this<br> <kbabbitt> s/MW/MQ/<br> <bramus> … suggestion earlier in the thread to do sth similar to viewport have the color-scheme meta value reflect in the MQ<br> <bramus> … there was reasonable pushback, but one of the final things is that we have an API in MQ5 for controlling the preference<br> <bramus> … and that by itself should be sufficient for my use-case (the switcher that does not require style repetition)<br> <bramus> … there have been an number of new comments though (that I see now)<br> <bramus> … was prepared to close as no-change, but need to review new comments<br> <bramus> florian: if someone could explain how this preference override thing works, then it might help with the discussion<br> <TabAtkins> https://drafts.csswg.org/mediaqueries-5/#script-control-user-prefs<br> <bramus> TabAtkins: the author of the page can call a method to override the value, which adjusts the MQ-visible value of that particular preference<br> <bramus> … you can also reset it to whatever the user had<br> <astearns> ack lwarlow<br> <bramus> lwarlow: I dont think the meta value should impact the MQ<br> <bramus> … we have mechanisms without script-control<br> <bramus> … if you set it to light dark the one that comes through the MQ will also ???<br> <bramus> … if you want to override you can set to either light or dark<br> <bramus> … the MQ to me are the ueser’s preference value and should reflec tthat<br> <bramus> … the script control can override that if needed<br> <bramus> … would be weird to override the ???<br> <JoshT> q+<br> <bramus> … would personally prefer no change<br> <astearns> ack florian<br> <bramus> florian: agree that the MQ should continue to reflect the user preft<br> <bramus> … so would also like to reject the change<br> <bramus> … maybe should we add another MQ such as active-color-scheme<br> <lwarlow> q+<br> <bramus> … however with tab}s thing that might not be entirely necessary<br> <bramus> … no change seems fine<br> <astearns> ack JoshT<br> <bramus> JoshT: last comments were making a similar piont to not change the MQ<br> <bramus> … we also have the if() for getting the used value<br> <bramus> … and the CQ<br> <bramus> … so that is even better than the active=color-scheme for the whole page<br> <bramus> … one concern though: if anyone was trying to implement a switch and store it in a cookie, there might be a flash of light theme until the script to change it runs<br> <bramus> … script could be made blocking<br> <bramus> TabAtkins: should not be an issue with the preference manager<br> <bramus> … it applies to the entire origin and should still be the same value<br> <bramus> JoshT: which resolves that issue<br> <bramus> … one more thing: johannes from NRK has been coming back to a lot of these similar issues where he would like to get the active color-scheme on img and video requests<br> <TabAtkins> that is, PreferenceManager is origin-persistent state, on the same level as cookies, so returning to the page later should maintain the override<br> <bramus> … been encouraging him to raise at WHATWG<br> <astearns> ack lwarlow<br> <bramus> lwarlow: one thing to bearin mind is stuff liek an active color scheme is not that entirely useful and you can change it down a tree<br> <bramus> … really we should be encouraging people to use if() and CQ<br> <bramus> … I think WHATWG should resolve img and subresource requests in general for this. The MQ is not always the right way here, can end up with contrast issues if things are mismatched.<br> <bramus> … CQ and if() are the way to do things on the used color scheme<br> <lwarlow> +1<br> <bramus> TabAtkins: so proposed resolution is close no change and rely on the preference manager<br> <bramus> astearns: concerns><br> <lwarlow> q+<br> <bramus> smfr: which UA have impelemted this API?<br> <bramus> bramus: none<br> <bramus> … there is a flag in chromium. implemented by lwarlow<br> <bramus> lwarlow: one thing is missing. some open issues at the WG still, but by and large it is there.<br> <bramus> … did raise standards positions. dont know about mozilla but webkit had concerns.<br> <bramus> … but not required for this issue here<br> <bramus> TabAtkins: yes, you would need to use a script with blokcing cookies, but is a doable thing<br> <bramus> lwarlow: need to implement the peristence thing<br> <tantek> is this the s-p you are thinking of? https://github.com/mozilla/standards-positions/issues/514<br> <TabAtkins> (the spec needs to be clarified a bit - the persistence is merely implied in the spec right now, as far as I can tell)<br> <bramus> smfr: would have an issue with this if this relies on the presence of the preference API<br> <lwarlow> https://github.com/WebKit/standards-positions/issues/252<br> <bramus> … pretty sure we”d object to sending the color-scheme stuff in client hints<br> <bramus> … fingerprinting vector<br> <TabAtkins> no, that's not the right s-p, tantek<br> <lwarlow> https://github.com/mozilla/standards-positions/issues/879 heres the mozilla oen<br> <bramus> astearns: (thinks)<br> <bramus> … if there is no preferences API would that change how we would like the meta tag to interact?<br> <bramus> smfr: dont know<br> <bramus> … ok with no change as long as others are<br> <bramus> … if the preferences API is never fully adopted<br> <bramus> TabAtkins: I can reopen later if needed<br> <bramus> … preferences API solves it properly<br> <bramus> … happy to close no change for now<br> <bramus> smfr: ok<br> <bramus> PROPOSED RESOLUTION: close no change<br> <JoshT> +1 to tab<br> <lwarlow> +1<br> <bramus> RESOLVED: close no change<br> <bramus> astearns: is josh correct about the concerns johannes raised? should HTML take that up?<br> <lwarlow> q+<br> <bramus> TabAtkins: if the prferecences API tha twill affect those. If not, then we will have to go reopen this issue an d worry about all that as well<br> <bramus> … should be solved the same way as the CSS stuff, and the prefefence manager API can do that<br> <bramus> … per the plan<br> <astearns> ack lwarlow<br> <bramus> lwarlow: I do think the image stuff isnt fully resolved with the prefecencs API, as the MQ is page global and you can have the used-color-scheme local on a subtree<br> <JoshT> +1<br> <JoshT> q+<br> <bramus> TabAtkins: sure. thats an even larger issue … even making it respond to the actual color scheme needs to be addressed too<br> <bramus> … right now pages always donwload the light image<br> <futhark> q+<br> <bramus> … keying off the local color scheme is a separate issue<br> <bramus> lwarlow: dont thing it is for ????<br> <bramus> … i dont thinkg fixing the prefers MQ because I thikn that people need local<br> <bramus> astearns: I wanted to make sure we didnt lose johannes’s comments, not solve this<br> <bramus> … josh, can you open a new issue with those comments?<br> <lwarlow> I think those comments need addressing at the HTML level as a new condition for keying off.<br> <bramus> JoshT: Yes<br> <astearns> ack JoshT<br> <astearns> ack futhark<br> <bramus> futhark: want to mention the problem with the local used color-scheme is simliar to load images based on CQs. You have to do a style and layout pass to figure out the value<br> <bramus> … kind of similar<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10249#issuecomment-3779908771 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 21 January 2026 17:27:08 UTC