Re: [csswg-drafts] [css-values-5] Using `if()` to do dark/light switching of image urls. (#10577)

The CSS Working Group just discussed ``[css-values-5] Using `if()` to do dark/light switching of image urls.``, and agreed to the following:

* `RESOLVED: Add color-scheme() test to both @container queries and if(). Open issue on what color-scheme() returns when used in color-scheme property.`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> astearns: proposed to add a color-scheme() test to if()<br>
&lt;emilio> q+<br>
&lt;fantasai> fantasai: is that cyclic?<br>
&lt;TabAtkins> add color-scheme() test to if(), which tests the used color scheme on the element<br>
&lt;astearns> ack emilio<br>
&lt;fantasai> emilio: should we look at inherited value?<br>
&lt;fantasai> TabAtkins: not cyclic because not looking at color-scheme property<br>
&lt;fantasai> s/not looking at/wouldn't work on<br>
&lt;fantasai> TabAtkins: Looking at parent color-scheme wouldn't be useful.<br>
&lt;fantasai> TabAtkins: It's not a complicated dependency, so should be straightforward.<br>
&lt;fantasai> TabAtkins: we can make color-scheme() test fail in color-scheme property.<br>
&lt;fantasai> emilio: There are typed custom properties as well...<br>
&lt;fantasai> TabAtkins: We already have spec mechanisms to handle arbitrarily complex dependency chains accurately<br>
&lt;fantasai> TabAtkins: this would add a dependency in<br>
&lt;fantasai> TabAtkins: same as using a style test depends on custom property<br>
&lt;fantasai> TabAtkins: thing to be concerned about is if likely that future language editions would create cycles that aren't already present<br>
&lt;fantasai> TabAtkins: but I think it's safe to say that color-scheme won't depend on anything in the future<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: I defer to impls on implementability<br>
&lt;TabAtkins> fantasai: but if we'll have special behavior on color-scheme prop to have it work, we should do the same as font-size/em<br>
&lt;TabAtkins> fantasai: it also makes a somewhat useful thing - you can do the opposite color scheme of your parent<br>
&lt;fantasai> astearns: Question of whether to add color-scheme() to container queries as well<br>
&lt;fantasai> fantasai: if we're doing the hard one we should do the easy one :)<br>
&lt;lea> +1 for color-scheme() on color-scheme resolving to parent color-scheme. I wish we had done that with var() too<br>
&lt;fantasai> TabAtkins: Agree we should keep them in sync.<br>
&lt;fantasai> PROPOSED: Add color-scheme() test to both @container queries and if(). Open question on what color-scheme() checks when in the color-scheme property.<br>
&lt;fantasai> fantasai: Can we just resolve on the color-scheme() checks parent color-scheme?<br>
&lt;fantasai> TabAtkins: unsure, let's leave it unresolved and discuss in other issue<br>
&lt;fantasai> RESOLVED: Add color-scheme() test to both @container queries and if(). Open issue on what color-scheme() returns when used in color-scheme property.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10577#issuecomment-3329616811 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 24 September 2025 15:53:57 UTC