Open tabatkins opened 5 months ago
fantasai
commented
3 months ago 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
commented
2 months ago 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
commented
1 month ago 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
commented
1 month ago 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: darkon:rootshould 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
commented
1 month ago 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
commented
1 month ago It's also worth mentioning the alternative for authors if
<meta name=color-scheme>and thecolor-schemeproperty don't affect theprefers-color-schemeMQs.
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
commented
1 month ago 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
commented
1 month ago 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 https://github.com/w3c/csswg-drafts/issues/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
commented
1 month ago The CSS Working Group just discussed [mediaqueries] Effect of <meta name=color-scheme> on the (prefers-color-scheme) MQ.
tabatkins
commented
1 month ago 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 <meta name=color-scheme content=dark> matching @media (prefers-color-scheme: light){...}?
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.
nt1m
commented
1 month ago @tabatkins I'm personally confused by the need for the change you're suggesting in the first place. If you specify <meta name=color-scheme content=dark> it means "my page only supports dark mode", so why do you even need to query the prefers-color-scheme media query in the first place? Can't you just write your page with dark colors?
nt1m
commented
1 month ago (Given that lack of use-case, I'd rather have it behave the same as setting color-scheme on the root for simplicity)
valtlai
commented
1 month ago @nt1m I think the use case is implementing a custom dark mode toggle more easily. Initially, you specify <meta name="color-scheme" content="light dark"> in the HTML. When the user interacts with the toggle, you use JS to update the content attribute value to light, dark, or the initial value, depending on the user’s choice.
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.
JoshTumath
commented
1 month ago @tabatkins I'm personally confused by the need for the change you're suggesting in the first place. If you specify
<meta name=color-scheme content=dark>it means "my page only supports dark mode", so why do you even need to query theprefers-color-schememedia query in the first place? Can't you just write your page with dark colors?
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.
tabatkins
commented
1 month ago If you specify it means "my page only supports dark mode", so why do you even need to query the prefers-color-scheme media query in the first place? Can't you just write your page with dark colors?
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 metas to affect the page in a way that is visible to MQs (namely, <meta name=viewport>). Having a consistent rule that meta elements can affect MQs would mean one less thing for authors to have to learn - given a particular chunk of HTML, whatever the result of that HTML is on the relevant qualities of the page, that's what the MQ tests on.
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?
mayank99
commented
1 month ago (#) It might be useful to get the author/OS's original preference, even if the page is currently overriding that preference.
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.
@tabatkins Are you suggesting that JS matchMedia should work differently from CSS @media? i.e. JS matchMedia should continue to not be affected by <meta name="color-scheme"> and only CSS @media should be affected?
johannesodland
commented
1 month ago
- We need to be able to respond to color-scheme changes on elements within the page, too, so we should design a style query for this instead.
...
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 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 <meta name=color-scheme> affect the MQ would make this easy to implement, a style query would not.
JoshTumath
commented
1 month ago @tabatkins Are you suggesting that JS
matchMediashould work differently from CSS@media? i.e. JSmatchMediashould continue to not be affected by<meta name="color-scheme">and only CSS@mediashould be affected?
This would need to be a new API. I don't think we would want to change how matchMedia works.
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 affect the MQ would make this easy to implement, a style query would not.
That's a really good point. The picture element is an important use-case to consider for this.
mayank99
commented
1 month ago This would need to be a new API. I don't think we would want to change how
matchMediaworks.
Then it's a moot point. There is a lot of JavaScript code out there that relies on matchMedia to get the original OS preference. If matchMedia suddenly starts being affected by <meta name="color-scheme">, then it can break all this code.
JoshTumath
commented
1 month ago Then it's a moot point. There is a lot of JavaScript code out there that relies on
matchMediato get the original OS preference. IfmatchMediasuddenly starts being affected by<meta name="color-scheme">, then it can break all this code.
Yeah it's a valid point, and we'd be in exactly the same position at the BBC. We also use matchMedia for our analytics to see what percentage of users have dark mode turned on in their OS settings.
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 prefers-color-scheme.
However, I'm still thinking about @johannesodland's point. It's clearly useful for the used colour scheme to affect <source media="(prefers-color-scheme: dark)"> elements in picture element. Even if we decide not to go ahead with @tabatkins's proposal and create a style query instead, surely we should we make an exception for that?
tabatkins
commented
1 month ago Are you suggesting that JS matchMedia should work differently from CSS @media? i.e. JS matchMedia should continue to not be affected by and only CSS @media should be affected?
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.
We also use matchMedia for our analytics to see what percentage of users have dark mode turned on in their OS settings.
Are you doing that on pages that currently have an explicit content="light" or content="dark" in their meta? Because if they're instead using content="light dark" (or not using the meta at all), it'll continue to act like it does today.
JoshTumath
commented
1 month ago Are you doing that on pages that currently have an explicit
content="light"orcontent="dark"in their meta? Because if they're instead usingcontent="light dark"(or not using the meta at all), it'll continue to act like it does today.
Currently none of our pages that support preferred colour scheme are using <meta name="color-scheme">. We use the CSS color-scheme property.
tabatkins
commented
1 month ago Right, so those would be unaffected in your logistics.
JoshTumath
commented
1 month ago Right, so those would be unaffected in your logistics.
Indeed. But if the <meta name="color-scheme"> does start affecting prefers-color-scheme, we're going to want to start using it to force some pages to a certain colour scheme, and that will affect the analytics. (But if there is an alternative API we can use to get the user's preference by the time this is implemented in browsers, we can easily switch to that.) But that's just the BBC. @mayank99 is concerned about other websites where their scripts are reliant on prefers-color-scheme always reflecting the user's preference:
Then it's a moot point. There is a lot of JavaScript code out there that relies on
matchMediato get the original OS preference. IfmatchMediasuddenly starts being affected by<meta name="color-scheme">, then it can break all this code.
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 <meta name="color-scheme" content="dark">, then they're unlikely to need to query prefers-color-scheme in a script (except for analytics).
@mayank99, do you have any other use cases in mind that you're concerned about?
bramus
commented
1 month ago 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 <meta name="color-scheme" content="dark"> change the reported value in the prefers-color-scheme feature query would circumvent that code duplication issue.
mayank99
commented
1 month ago @JoshTumath @tabatkins My main point is that matchMedia is a reliable way to get the user's preferred color-scheme today. If it suddenly starts changing based on the markup, then it is no longer reliable.
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 <meta name="color-scheme"> in the <head> and matchMedia in the <script> at the bottom).
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 color-scheme started shipping in browsers.
@bramus Style queries do help with deduplication. The key is to also explicitly set the property based on the prefers-color-scheme query. I've created an example using custom property style queries that you can inspect. I imagine one day you'd be able to remove the custom property and directly set color-scheme. It might initially seem redundant to set color-scheme to be able to query it, but it fits my mental model that media queries are about the medium, while style queries are about the actual styles.
(Also light-dark() is a great way of solving duplication)
bramus
commented
1 month ago @bramus Style queries do help with deduplication.
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 prefers-color-scheme media query in their stylesheets. The nicest solution to the original issue is not to require them to do a pretty big rewrite of their styles.
It might initially seem redundant to set
color-schemeto be able to query it, but it fits my mental model that media queries are about the medium, while style queries are about the actual styles.
Agreed that there definitely is a conflict here: prefers-color-scheme is about the user’s preference, not the author’s preference.
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 that says “Hey, I’m fine with the meta tag overriding the prefers value”?
@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 (prefers-color-scheme) MQ broken by default? If we recommend authors always do this new thing, why are we leaving the old thing around at all?
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 width/height MQs versus the <meta name=viewport>? If we asked "why do we let a meta affect those MQs, that's within-document information", the obvious answer is "because the 'original dimensions' isn't a useful concept for the page to use for styling, so why would we expose them?". The exact same question applies here.
romainmenke
commented
1 month ago 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.
kizu
commented
1 month ago I published a new post today: “Querying the Color Scheme” about how we can use style queries, registered custom properties and light-dark() to query the value of the color-scheme on any element, including the root one. Here is a CodePen: https://codepen.io/kizu/pen/YzojgZP
The way color-scheme is defined in the specs is such:
The color-scheme property allows an element to indicate which color schemes it is designed to be rendered with. These values are negotiated with the user’s preferences, resulting in a used color scheme that affects things such as the default colors of form controls and scrollbars. (See § 2.2 Effects of the Used Color Scheme.)
There is an important distinction between it and the user preferences. The @media (prefers-color-scheme) is specifically about the user preference, and not about the used color scheme.
Expecting the <meta name=color-scheme content=dark> to impact the @media is an author mistake, and if we had a built-in container query for querying the “used color scheme” (or just allow the color-scheme in the @container style(color-scheme: light | dark)), it would be trivial for the authors to specify the styles which would be based on the <meta>. The meta tag, in this case, just says that the page is designed with the corresponding schemes in mind, and it up to the authors to actually design it appropriately.
JoshTumath
commented
1 month ago I think I am more persuaded, now, that some kind of style query could be the right approach. That way, the prefers-* queries will always reflect the user settings. Authors could replace many of their (prefers-color-scheme) media queries with it. But I'm still concerned about the following:
picture element to select different images for light and dark mode. The source element accepts media queries in a media attribute but doesn't accept style queries, and realistically never could (unless maybe the image is lazy loaded).bramus
commented
1 month ago
- Authors will want to think about backwards compatibility if we encourage them to use a style query instead. There would have to be a way for them to transition. Would they have to define their styles twice, as @bramus explained? [mediaqueries] Effect of on the (prefers-color-scheme) MQ #10249 (comment)
https://github.com/w3c/csswg-drafts/issues/10249#issuecomment-2309778794 addresses that.
JoshTumath
commented
1 month ago #10249 (comment) addresses that.
Something like a @config tag would definitely help! Then authors don't need to change their code. But any change to the MQ syntax like using @when will delay when authors can start using this feature or they'll have to duplicate their code.
tabatkins
commented
1 month ago There is an important distinction between it and the user preferences. The @media (prefers-color-scheme) is specifically about the user preference, and not about the used color scheme.
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 <meta name=color-scheme content=dark>. The used color scheme is gonna be dark (unless some other styles explicitly override that with a color-scheme property), so if the user preference (or rather, the preference communicated to us by the OS) is light, the MQ will select the wrong colors and the page will have a broken appearance.
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 https://github.com/speced/respec/issues/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 (prefers-color-scheme) is labeled a "user-preference media query", it seems to make sense that it strictly reflects the user preference. But we need to take a broader view and make sure we're best serving the actual purpose of the MQ, not what we happened to have used to describe it. And that purpose is "select the correct set of colors, and related styles, to reflect the page's color scheme (which can be set by the user)".
kizu
commented
1 month ago 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 @config or something, it could help with this use case. But that would be a precedent for allowing overriding a media query value from CSS.
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 <meta> impacting the media query, if both an author and a user will still be able to somehow get the actual value of prefers-color-scheme and adjust things accordingly.
Crissov
commented
1 month ago The media query prefers-color-scheme is always about a user preference as configured in the browser or operating system settings. The color-scheme <meta> in HTML is set by the author, but may be informed by a user choice expressed in the webpage. Since it could still just reflect the author’s preference it must not compete with the actual user preference. That is the author’s job to handle, not the W3C’s nor the browser’s!
That is, if they are using the meta, they should probably not be using the MQ, but to achieve this, in-page switches for user preferences would need to be able to access from CSS in a different way. The usual and proper way would be a pseudo-class selector, i.e. either :light and :dark or :color-scheme(), because those frequently depend on the host markup. In most cases selectors are not the same document-wide, but I am not the one to know whether this metadata may become available for certain elements on the page independently.
mirisuzanne
commented
3 weeks ago @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 color-scheme on root? Maybe helping me control what flash of pre-style color people will see? Does the meta tag do that?
In either case, we need the used-value query.
JoshTumath
commented
3 weeks ago 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.
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?