- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 31 Mar 2026 23:30:22 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[mediaqueries] Effect of <meta name=color-scheme> on img and video sources`, and agreed to the following: * `RESOLVED: (prefers-color-scheme) reflects <meta name=color-scheme>. Add (bikeshed-color-scheme) to always reflect the preference coming from the browser. (pending feedback from other commenters in the issue)` <details><summary>The full IRC log of that discussion</summary> <emilio> TabAtkins: if you set `<meta name=color-scheme>` it changes the used color-scheme, but media queries don't affect it<br> <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/31-css-minutes.html fantasai<br> <emilio> ... the `<picture>` lets you switch between multiple different sources based on media query<br> <emilio> ... if you have `<picture>` but `<meta name="color-scheme" content="dark">`, but os in light mode, prefers-color-scheme doesn't match<br> <emilio> TabAtkins: we could special-case picture / video to make their media query resolve differently (not in love)<br> <emilio> ... make media queries look into the meta<br> <emilio> ... or make sure that there's a way to use the used color-scheme of the video / picture<br> <emilio> q+<br> <emilio> ... but would require more interaction with HTML and not fix any existing light / dark mode picture<br> <emilio> ... thoughts?<br> <emilio> ... my proposal would be to make the media query use the meta color scheme<br> <emilio> ... I think it's the cleanest way to solve several of these<br> <emilio> ... other solutions would be great<br> <emilio> ... the current state is quite bad<br> <astearns> ack fantasai<br> <emilio> fantasai: alternative proposal, new `color-scheme` media query that reflects the document, so `prefers-color-scheme` reflects the user preferred color scheme<br> <florian> I think I like fantasai's proposal<br> <emilio> fantasai: so you can do your queries for the `color-scheme` without interacting with the preferred value<br> <TabAtkins> emilio: I dont' like that proposal. `prefers-color-scheme` already takes into account the embedder page; if your outer page is in light mode, an iframe will match (prefers-color-scheme: light)<br> <astearns> ack emilio<br> <TabAtkins> emilio: I don't like any of them too much, but I think Tab's is the least destructive<br> <fantasai> emilio: why would you mismatch?<br> <fantasai> TabAtkins: You might have a switcher on the page.<br> <fantasai> TabAtkins: Do that by setting the meta<br> <fantasai> emilio: Didn't we have scripted control thing?<br> <fantasai> TabAtkins: yes, but also, one page might be forced dark mode while you're using generic assets that are styled for both<br> <fantasai> emilio: This would only affect things in the markup, right?<br> <fantasai> emilio: For other things you'd use light-dark function<br> <fantasai> emilio: Feels a bit annoying in that preloading for picture resources, now would need to account for that.<br> <fantasai> emilio: E.g. parsing HTML speculatively, you assume that the media is going to match and now you need to account for the meta tag changing, which is a bit wasteful<br> <fantasai> TabAtkins: while potentially wasteful, it is avoiding loading the wrong resource<br> <astearns> s/avoiding loading/avoiding displaying/<br> <fantasai> TabAtkins: That would only be an issue if you changed the meta well after preload<br> <fantasai> emilio: Your scanner would need to account for the meta<br> <fantasai> TabAtkins: how does it interact with viewport meta's today?<br> <fantasai> emilio: It doesn't :)<br> <fantasai> emilio: It's explicitly bad because [something]<br> <TabAtkins> s/something/without the viewport meta, the viewport size depends on the content in some ways/<br> <fantasai> emilio: Any other meta tag other than device-width is realistically not common enough to optimize<br> <fantasai> emilio: tldr, I think Tab's proposal is the least bad but still eh<br> <astearns> ack fantasai<br> <emilio> fantasai: tabs and my proposal is effectively the same other than with other name right?<br> <emilio> emilio: yeah but I still think changing prefers-color-scheme is fine<br> <emilio> fantasai: there were some concerns about that<br> <emilio> ... we wouldn't have done the embedder thing if we had this<br> <emilio> emilio: but then prefers-color-scheme is pretty useless<br> <emilio> fantasai: you'd use prefers-color-scheme to set the initial switcher state or so<br> <emilio> ... we have several meta tags that are going to affect media queries, the viewport meta tag, the color-scheme, the text-scale which will also affect media queries<br> <florian> q+<br> <fantasai> emilio: Not sure I buy need for distinguishing color-scheme and prefers-color-scheme<br> <fantasai> emilio: prefers-color-scheme already responds to the embedding page color scheme<br> <fantasai> emilio: We need a different concept for this, because the used color scheme for lacking a meta tag is light.<br> <fantasai> emilio: even if that's not the preferred color scheme<br> <fantasai> emilio: Given how it's already not quite the user's preferred color scheme<br> <fantasai> emilio: I find it a bit more acceptable to re-use it.<br> <fantasai> emilio: If it wasn't influenced by the embeder page, then I could see the distiction being meaningful<br> <fantasai> emilio: but right now it's pretty arbitrary<br> <astearns> q+<br> <astearns> ack florian<br> <emilio> florian: I think I'd have a strong preference if we were in a clean slate<br> <TabAtkins> Just as a reminder, the only argument we had for (prefers-color-scheme) remaining unchanged is so that certain data-collection schemes can still tell what the user preferred even on pages with a <meta color-scheme> manually set<br> <emilio> ... the fact we're not I think I still lean towards fantasai's approach but less strongly<br> <emilio> ... if a page has mixed color-schemes<br> <emilio> ... let's say you have a "spec browser" with its own picker which sets the meta<br> <emilio> ... within that, the color-scheme media would respond to the meta, which ??<br> <emilio> ... specs have light and dark mode<br> <emilio> ... you might have a preference for that<br> <emilio> ... instead of viewing them and it's not in an iframe<br> <emilio> ... so you have a picker in the gallery but having access to the OS level preference would allow you to render the iframe in the right color scheme<br> <emilio> emilio: ah so you have an iframe and you want the "system" color scheme on the iframe<br> <emilio> florian: how locked in are we on the iframe thing?<br> <emilio> ... if we had a color-scheme media query, we could use _that_ for the iframe<br> <TabAtkins> emilio: so my problem with (color-scheme) is that, it's the MQ you want for everything in practice. We have all this code and examples already using (prefers-color-scheme)...<br> <TabAtkins> emilio: so when would you want the actual (prefers-color-scheme)?<br> <TabAtkins> emilio: I agree in an ideal world we'd have done (color-scheme) originally, but...<br> <fantasai> TabAtkins: The original argument for keeping them distinct was collecting user data<br> <fantasai> emilio: For Firefox browser UI we need this distinction<br> <fantasai> emilio: We need to use the user's preference for the UI<br> <fantasai> emilio: I added a new MQ with a different name for the UI vs the web content<br> <fantasai> emilio: Given massive amount of code using 'prefers-color-scheme' that would need to change<br> <fantasai> emilio: can we instead add a new MQ for the "system preferred scheme"?<br> <fantasai> florian: I think we do want both. Though naming whatever.<br> <fantasai> emilio: Internally we have concept of "used" and "preferred" color schemes<br> <fantasai> emilio: I don't have a great name... it's not really the system color scheme<br> <fantasai> emilio: Potentially 3 color schemes involved<br> <fantasai> emilio: 1. One that the page sets.<br> <fantasai> emilio: 2. One that the embedder sets.<br> <fantasai> emilio: 3. The browser's color scheme.<br> <fantasai> emilio: 4. OS color scheme.<br> <fantasai> ....<br> <fantasai> emilio: There's the top-level value that the browser sets for the top-level page.<br> <fantasai> emilio: Then there's the one that your embedder sets, e.g. on an iframe.<br> <fantasai> emilio: Then there's the one set by the iframe document itself.<br> <fantasai> emilio: We only have name for one of these<br> <fantasai> emilio: Least disruptive approach is introducing a new name for the one you most likely don't want to use.<br> <fantasai> astearns: Emilio, you're worried about compat because we already have documentation and use of prefers-color-scheme<br> <fantasai> astearns: If we follow Elika's proposal to introduce a new MQ, then content would need to move over to the new feature.<br> <miriam> q+<br> <fantasai> astearns: But if we follow Tab's proposal to re-interpret prefers-color-scheme, then we break existing behavior / uses.<br> <fantasai> astearns: With both ideas, we'd be changing the prefers-color-scheme in some way...<br> <fantasai> astearns: Maybe we can shift to better names for things?<br> <fantasai> emilio: Not sensible. A lot of SVG icons using prefers-color-scheme right now. Changing that beahvior would break things.<br> <astearns> ack astearns<br> <fantasai> emilio: With Tab's proposal, if you only have one <meta> value then the behavior changes, but only if you have one of them.<br> <fantasai> astearns: Then we're locked into not quite ideal name.<br> <astearns> ack miriam<br> <fantasai> miriam: One other use case, there are variations. Lighter light modes, and darker dark modes, and darker light mods, and lighter dark modes.<br> <fantasai> miriam: So reasonable to say that you're in a dark mode with a light mode preference, and combine these two preference to choose.<br> <fantasai> emilio: Maybe use ua-prefers-color-scheme or something?<br> <fantasai> emilio: And that gets you the top-level preference.<br> <fantasai> emilio: If there wasn't tons of existing content, Elika's suggestion is strictly better.<br> <fantasai> TabAtkins: Proposal: Go ahead and change the prefers-color-scheme on the top-level page to follow color-scheme meta value.<br> <fantasai> TabAtkins: Also add a new media query that only responds to the user's preference, ignoring anything the content does.<br> <fantasai> fantasai: So like prefers-color-scheme reflects the color scheme resolved via <meta color-scheme>, and user-color-scheme reflects the user preference always.<br> <TabAtkins> ua-prefers-color-scheme<br> <TabAtkins> (name technically TBD)<br> <fantasai> TabAtkins: And the JS API would not change the new one.<br> <florian> wfm<br> <fantasai> fantasai: Suggest we summarize the proposal into the issue, then resolve once we can cycle back to the people who had opinions.<br> <TabAtkins> PROPOSED: (prefers-color-scheme) reflects <meta name=color-scheme>. Add (bikeshed-color-scheme) to always reflect the preference coming from the browser.<br> <florian> +1<br> <TabAtkins> PROPOSED: (prefers-color-scheme) reflects <meta name=color-scheme>. Add (bikeshed-color-scheme) to always reflect the preference coming from the browser. (pending feedback from other commenters in the issue)<br> <TabAtkins> RESOLVED: (prefers-color-scheme) reflects <meta name=color-scheme>. Add (bikeshed-color-scheme) to always reflect the preference coming from the browser. (pending feedback from other commenters in the issue)<br> <iank_> are we doing any other issues today? or just republishing stuff?<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13377#issuecomment-4166335486 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 31 March 2026 23:30:23 UTC