[mediaqueries] Effect of <meta name=color-scheme> on the (prefers-color-scheme) MQ

[tabatkins]

Currently, it appears that the <meta name=color-scheme> element has no effect on the (prefers-color-scheme) MQ. This seems unfortunate; setting <meta name=color-scheme content=dark> does switch the default colors on the page to darkmode, but the styles still match (prefers-color-scheme: light), resulting in inconsistent behavior.

It does appear that this is an oversight between Color Adjust, MQ, and the HTML spec. Currently the meta element affects the "supported color schemes", which is then used solely by the color-scheme property to restrict what values it can be set to.

Am I wrong in thinking that it should indeed also affect the MQ, in the same way?

[fantasai]

Am I wrong in thinking that it should indeed also affect the MQ, in the same way?

I think so? The color-scheme meta is about setting color-scheme, which also does not cause a change in prefers-color-scheme.

[tabatkins]

It currently does only that, yes. My question is if it should be treated as doing more, because it communicates the color scheme at a level that is above CSS, and thus is theoretically available for adjusting MQs. Like, the viewport meta can change the screen size, which affects the width/height MQs; it would be pretty worthless if those MQs matched just on the size that the screen would have been without the viewport meta.

[bramus]

I don’t have an opinion (yet) on whether the meta value should affect the result of the MQ but if it does, then declaring color-scheme: dark on :root should also have a similar outcome, no?

[JoshTumath]

Whatever is decided, I would expect authors would think that <meta name=color-scheme> and the color-scheme property are equivalent and have the same behaviour. I agree with @tabatkins that they should affect the prefers-color-scheme media query.

but if it does, then declaring color-scheme: dark on :root should also have a similar outcome, no?

I actually thought it already did, but apparently not. I tried in a CodePen and found that it does change the background colour of the page, but doesn't affect the media queries.
https://codepen.io/joshtumath/pen/ExBbrpy?editors=1100

[JoshTumath]

It's also worth mentioning the alternative for authors if <meta name=color-scheme> and the color-scheme property don't affect the prefers-color-scheme MQs.

If there is a design intent for a particular page of a website to always use dark mode (such as a video page, as is the case on the BBC Sport website), then it's just extra effort for authors to override where they've set light-dark() to force a particular colour.

[bramus]

It's also worth mentioning the alternative for authors if <meta name=color-scheme> and the color-scheme property don't affect the prefers-color-scheme MQs.

You could use a custom property and a style query. Requires setting a custom prop on * though (blanket mode), to work around custom props getting computed before inheriting (until we get style queries on regular props).

[JoshTumath]

Thinking about this further, it seems even stranger if it was agreed in #7213 for color-scheme to affect prefers-color-scheme MQs in embedded SVGs but not in HTML content.

[tabatkins]

I don’t have an opinion (yet) on whether the meta value should affect the result of the MQ but if it does, then declaring color-scheme: dark on :root should also have a similar outcome, no?

No, that would be cyclic, since you can vary what you set that value to based on MQs. This would exclusively be an information flow from HTML to CSS.

You could use a custom property and a style query.

Oooof, that's nasty.

it seems even stranger if it was agreed in #7213 for color-scheme to affect prefers-color-scheme MQs in embedded SVGs but not in HTML content.

That's a different case; it's about propagating the information from the outer document into the inner document's MQ. This is about the document itself being able to set that MQ, from its own meta tags.

[css-meeting-bot]

The CSS Working Group just discussed [mediaqueries] Effect of <meta name=color-scheme> on the (prefers-color-scheme) MQ.

The full IRC log of that discussion

<matthieud> TabAtkins: Dark mode and spec is weird : when the meta makes the page dark, it is not reflected in the value of the media query
<matthieud> TabAtkins: proposition we allow the meta name color-scheme to define the value of the prefers-color-scheme MQ
<matthieud> TabAtkins: Uniflow imformation from page to the CSS ; it' s similar to how the viewport meta affect the size MQ on the page
<emilio> q+
<astearns> ack emilio
<matthieud> emilio: It makes sense. If someone does the opposite (set the meta from the value of the MQ?) no reason to do that though
<joshtumath> q+
<matthieud> TabAtkins: no reason to do that (set meta from MQ)
<astearns> ack joshtumath
<matthieud> joshtumath: How this work with color-scheme property ?
<matthieud> TabAtkins: It still has no effect of the result of the prefer-color-scheme MQ
<astearns> ack fantasai
<matthieud> fantasai: Currently the color-scheme meta is just setting the color-scheme property. But now it would have a new behavior (affecting the MQ)
<matthieud> TabAtkins: it makes more sense than having MQ giving the result of the OS
<emilio> q+
<matthieud> fantasai: But setting color-scheme property on the root doesnt affect the MQ
<matthieud> TabAtkins: Nobody expecty properties to affect MQ, but it' s more reasonable for the HTML (like meta) to affect the MQ
<astearns> ack emilio
<fantasai> TabAtkins: If I set color-schemen, I get dark controls, but prefers-color-scheme doesn't reflect, so that's confusing
<matthieud> emilio: Do we have data on the usage of this ?
<joshtumath> q+
<fantasai> fantasai: But if you set color-scheme property on the root, you also get dark controls, and prefers-color-scheme doesn't reflect there either
<matthieud> TabAtkins: anecdotal I got bit by this behavior already
<miriam> q+
<astearns> ack joshtumath
<ntim> q+
<matthieud> joshtumath: As author, I'm often confuse between using the meta tag vs the css property
<emilio> q+
<matthieud> joshtumath: Are they equivalent ? Now they would not be equivalent anymore
<matthieud> joshtumath: And also weird when using the property on the root
<matthieud> TabAtkins: they are the same right now
<matthieud> emilio: Not really, the meta change the value of "normal"
<astearns> ack miriam
<emilio> ack emilio
<matthieud> miriam: We've discussed similar stuff with the Preferences API (changing the result of MQ)
<matthieud> miriam: As author, I'm sometimes interested to know what the user (the OS) setting is even if I overwrite with the property
<fantasai> +1 miriam
<joshtumath> q+
<matthieud> miriam: I would like to be able to query the normal setting on the page (so no overwrite of the MQ) ; but I'm also interested into overwriting it
<matthieud> emilio: You can already modify the preferences (with iframe or svg?)
<fantasai> [prefers-color-scheme on embedded content takes the value from the embedding element's color-scheme]
<matthieud> TabAtkins: Assuming you are on a page with has set the meta to dark. What is the goal of knowing the original user value ?
<matthieud> s/with/which
<matthieud> miriam: Not sure, interesting to know if my author default is different from the user default. Like for example providing a toggle if they don't match
<matthieud> TabAtkins: That would use javascript
<matthieud> miriam: yes but it would be more robust with html
<matthieud> TabAtkins: But it doesn't work today. If meta is dark, and you use the MQ to set style, you will have inconsistent result
<astearns> ack ntim
<kizu> q+
<astearns> zakim, close queue
<Zakim> ok, astearns, the speaker queue is closed
<matthieud> ntim: meta tag values are the same as the property, but MQ only supports a subset of them
<astearns> ack joshtumath
<matthieud> TabAtkins: The proposal is that the prefers MQ takes into account the meta tag ; so it just match only the used value of the color-scheme property (so no issue)
<matthieud> joshtumath: Maybe we need a new MQ
<matthieud> TabAtkins: If we introduce a new MQ which take into account the meta, there would not be any use for the original one which only reflect the OS value
<ntim> q+
<matthieud> TabAtkins: it could be a JS API if we really want to have the default value without the meta
<astearns> ack kizu
<miriam> curious if that's true...
<matthieud> kizu: +1 for this as a style query
<matthieud> TabAtkins: style quuery is nice to do non color styling, but it is useful for the MQ to differ from the style query ?
<matthieud> TabAtkins: do we want both mechanism ?
<matthieud> astearns: in your solution the MQ and the style query would differ when you set value on the root
<matthieud> TabAtkins: Yes
<TabAtkins> <meta name=color-scheme content=dark>, then `color-scheme: light dark`
<matthieud> kizu: if html meta dark with only 1 value, but author css color-scheme root both light and dark. What do we do ? Author might want to override this
<matthieud> TabAtkins: preference for this should affect how the color-scheme property resolves
<astearns> ack fantasai
<Zakim> fantasai, you wanted to back up suggestion of style query being more appropriate here
<matthieud> fantasai: the style query makes more sense
<matthieud> fantasai: we want to used value and not the computed value here
<matthieud> fantasai: if you change the color-scheme in the middle of the page, but other part you want the user preference "normal", Tab solution doesnt work
<matthieud> fantasai: Only works with a style query
<matthieud> fantasai: It would avoid the confusion between color-scheme meta and color-scheme MQ
<matthieud> fantasai: And you can do a container query on the root to get the value of the meta tag
<emilio> +1 to TabAtkins, not sure they need to be exclusive
<matthieud> TabAtkins: Elika solution is nice, let's go back to the issue
<fantasai> It would need to be a color-scheme() function
<matthieud> TabAtkins: my solution is still valid
<fantasai> since the computed value wouldn't work for this purpose
<fantasai> we need the used color-scheme