[mediaqueries] Effect of <meta name=color-scheme> on the (prefers-color-scheme) MQ #10249
Comments
I think so? The |
|
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 |
|
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 |
|
Whatever is decided, I would expect authors would think that
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. |
|
It's also worth mentioning the alternative for authors if 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 |
You could use a custom property and a style query. Requires setting a custom prop on |
|
Thinking about this further, it seems even stranger if it was agreed in #7213 for |
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.
Oooof, that's nasty.
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. |
|
The CSS Working Group just discussed 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 |
|
From the discussion, there were two significant pushbacks:
For (1), I accept that this information might be useful, but not useful within static CSS. If you need this info, it'll be in JS, as part of a larger preference-handling mechanism. I'm open to being corrected, but currently I see no possibly reason you would want to style the page based on a color scheme not being used on the page. Getting this information (the original preference) from a JS API sounds reasonable, tho. For (2), I agree that would be useful (and agree that it needs a special mechanism, since it's about the used color scheme, not the computed value, which SQs currently match on). What I disagree is that this is something we should do instead of my proposal. I think they're both useful! Notably, circling around to my response to (1), even if we designed such an SQ, in what world is it useful to continue to provide authors with the ability to style the page based on a color scheme that's not being used? What's the use-case for a page with So I'm just confused by this response being an objection. If we think the SQ approach would be more useful, are we going to just recommend that authors only use this mechanism, and mark the MQ as deprecated and recommend against its use? If we don't do that, what does our author guidance for the MQ look like? @fantasai, could you elaborate more on why the existence of a proper SQ for color-scheme means we should leave the MQ as it is? I'd love to see a hypothetical use-case. |
|
@tabatkins I'm personally confused by the need for the change you're suggesting in the first place. If you specify |
|
(Given that lack of use-case, I'd rather have it behave the same as setting color-scheme on the root for simplicity) |
|
@nt1m I think the use case is implementing a custom dark mode toggle more easily. Initially, you specify I know the Web Preferences API proposal would solve this even better (no flash of the default color scheme on static sites on load), but maybe the proposed change in this issue would be implemented sooner. |
If a website has a mixture of pages that respond to the colour scheme preference and pages that use light/dark mode only, it's still most likely going to share the same stylesheet. Authors aren't going to want to switch out to a separate stylesheet just for pages that override to light/dark mode. |
Your CSS can easily be written for a wide variety of pages (supplying both light and dark styles), and the meta only used to force a color-scheme on certain ones. (what @JoshTumath said) (The in-page color-scheme toggle is also a use-case, and in fact why I originally ran into it, but the Web Preferences API is the better solution for this anyway, so I'm not gonna lean on that as as argument.) But there's also, more generally, the author-consistency/advice argument. We allow some As I said, I don't see what the author-benefit argument is for allowing the MQ to match on a value that the page is not using. Why do we want to give authors a confusing MQ, when we can just as easily make it match expectations? |
@tabatkins Are you suggesting that JS |
I agree with @tabatkins. Having a style query would be useful, but it doesn't cover all the use cases of the proposal. We often have the need to provide separate image and video sources for darkmode. This is currently hard to do as we have a custom darkmode setting on our site. Having |
This would need to be a new API. I don't think we would want to change how
That's a really good point. The |
Then it's a moot point. There is a lot of JavaScript code out there that relies on |
Yeah it's a valid point, and we'd be in exactly the same position at the BBC. We also use The proposed change is likely to cause these kinds of compatibility issues. @fantasai 's proposal of a style query would solve this problem. We wouldn't have to worry about author's relying on the current behaviour of However, I'm still thinking about @johannesodland's point. It's clearly useful for the used colour scheme to affect |
No, I'm talking a new API to fetch the "original" preference (possibly something hanging off the Web Preferences API). Having all uses of MQs be consistent is definitely required, I think.
Are you doing that on pages that currently have an explicit |
Currently none of our pages that support preferred colour scheme are using |
|
Right, so those would be unaffected in your logistics. |
Indeed. But if the
So I guess the question is: how bad would the impact of this change be if it does 'break all this code'? I've brought up the analytics use case but maybe there are others? Would it actually be a problem? The counterargument to that is: if an author is setting an explicit colour scheme by setting @mayank99, do you have any other use cases in mind that you're concerned about? |
|
Focusing on the style query: I don’t think that will be a closing solution as it would require authors to duplicate their code: @media (prefers-color-scheme: dark) {
…<dark-styles>
}
@container style(color-scheme: dark) {
…<dark-styles>
}It’s also no different than simply checking for the presence of the meta tag in the head @media (prefers-color-scheme: dark) {
…<dark-styles>
}
html:has(meta[name="color-scheme"][content="dark"]) {
…<dark-styles>
}In both cases you end up with duplicated code, which is not ideal. That code duplication issue was also one of the reasons behind the Web Preferences API, so that authors no longer need to duplicate their styles when the preference is overridden. Tab’s original suggestion to have |
|
@JoshTumath @tabatkins My main point is that Often times, the HTML and JS are not even written by the same author. The JS might even be coming from a third-party script or a browser extension. Can you really be sure that nothing will break with this change? To illustrate this point, I've created an example that would break if such a change was to ship (you can inspect the page to see I'm not necessarily opposed to the proposed behavior (even though I personally feel it makes things more confusing), but I think that ship has sailed. The right time to make this change would have been five years ago before @bramus Style queries do help with deduplication. The key is to also explicitly set the property based on the (Also |
I’ve mentioned a similar workaround here. But that’s quite a nasty hack which requires quite some cognitive load from authors. The recommended approach for authors always has been to use the
Agreed that there definitely is a conflict here: Maybe, ideally, it’d be something like the following? @when (media(prefers-color-scheme: dark) or (document(single-color-scheme: dark)) {
…<dark-styles>
}This way it’s clear that the one thing is a user’s preference, whereas the other thing is an author/document preference. Or maybe it could be an option for something like @config {
forced-color-scheme-from-meta: true;
} |
|
Again, the question with any of these options is: what value are we providing to authors by leaving the The only value that has been brought up is the possibility of JS that wants to know the actual user preference, even if it's not currently being used on the page, either for creating a style-picker or doing analytics. Neither of these require the media query to reflect any particular value; they'd both be fine with us providing a new API that returns the value. And to reiterate an earlier point: what's the difference between this case and the |
|
I also think it makes sense that "user preference" is within the context of the device, browser, current document and stays within the available options. I think @tabatkins's proposal gives the least surprising behavior for end users and most CSS authors. |
|
I published a new post today: “Querying the Color Scheme” about how we can use style queries, registered custom properties and The way
There is an important distinction between it and the user preferences. The Expecting the |
|
I think I am more persuaded, now, that some kind of style query could be the right approach. That way, the
|
#10249 (comment) addresses that. |
Something like a |
Ignoring the effect of actually setting the 'color-scheme' property, I must ask once again - what is the benefit to authors of this distinction? Is there a benefit to anyone else, either? I think the answer is definitely no. Excepting the corner cases already discussed (analytics and JS-based color pickers, which can pick up the information from some other JS API instead and don't require the MQ itself), afaict there is absolutely no reason an author would ever want to style a page based on the current user preference when the page has Similarly, I don't see any user benefit to this. Pages can already ignore the user preference whenever they like by just not using the MQ at all. If an author has explicitly set the page's color scheme, it similarly is an indication that they know they're using a particular scheme regardless of user preference. (And, importantly, a big reason to do so is specifically to reflect a user preference from an in-page color-scheme picker! See speced/respec#4687 for an example. It's important to remember that the user's color preference for their OS isn't always the same as the user's color preference for this page.) Afaict, having the MQ strictly reflect the user preference only brings the possibility of hurting the user, due to a page's colors being broken because of a mismatch in MQ and used color-scheme. So as far as I can tell the only party to benefit from "(prefers-color-scheme) must strictly match the user preference" is Theoretical Purity, the lowest of all our constituencies. (And, to a tiny degree, browsers, just because it means they don't have to make any change.) Because |
|
As an author, if I had a style query, I would rarely use a media query for this purpose (being the source of truth for the dark colors on the page). As it would work only on the top level, and for any nested component where I'd want to invert the color scheme, it won't work. And it is already very easy for an author to misinterpret how media query works, and use it for components, breaking them when they are inserted into an inverted context. Another useful distinction between a media query and a style query in this case would be that you could implement a single dark theme, and still adapt it to the user preference. If the user prefers a light theme, that likely means their browser chrome and other windows around would have a light theme. An author, implementing a dark color scheme, can take this into account and make the colors more contrast, so the elements on the page won't be lost. But if the user preference matches the color scheme, we can adjust the colors and make them not as contrasting, making it so the bright elements on the page do not light up the room. Similarly, we could also implement a single light color scheme, but adapt it to the user preference when the user prefers a dark one, and dim it. Another possible case, on the user land, is custom style overrides for a page. If the page gets the value of the media query from HTML, the user loses an ability to write their styles that adapt to the user preference, as at this point there is no way to get this information. I guess, if we'd specify it so we somehow could switch the media query from CSS, via To sum up, I think there is a useful distinction between being able to ask “what the user wants?” and “what is the applied color scheme?”, and allow authors use a media query for one, and a style query for another, allowing reconciling the differences as a part of the design process. I'll be ok with the |
|
The media query That is, if they are using the |
|
@tabatkins The use-case that I have in mind is breaking out of simple light/dark binary thinking. There are lighter dark themes, and darker light themes, and a whole range in between. I will get a binary answer from the user OS preference query, and I have to (currently) provide a binary answer to the browser – but it's reasonable for my actual output to be adjusted when they mismatch. My site is light, but I know you prefer dark themes, so here is a toned-down version of my light theme. That seems to me like a reasonable use-case, and not one that should require JS. But I'm not sure what the meta tag would provide in that use-case over In either case, we need the used-value query. |
|
Should we make a new issue for the proposed used-value query? The proposed options for it, so far, are a style query or pseudo-class. |
Do we need a separate issue for a used-value media query as well? If we end up deciding that the meta value does not affect the |
I did bring that up, but most of the discussion has been around a style query. Do you imagine a media query would do something different to a style query or pseudo-class? |
I don’t think style queries or pseudo-classes solves the need to serve the appropriate media sources? |
|
I've been giving variations on a talk about using color-scheme for a while now - and interestingly I have not had anyone come to me confused about the difference between prefers-color-scheme and color-scheme - one coming from the OS settings and one being togglable in-page. An author might set I guess it's a moot point, that hypothetical author clearly isn't offering choice anyway. But that bothers me. |
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
metaelement affects the "supported color schemes", which is then used solely by thecolor-schemeproperty 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?
The text was updated successfully, but these errors were encountered: