- From: Tab Atkins Jr. via GitHub <noreply@w3.org>
- Date: Wed, 24 Sep 2025 17:15:17 +0000
- To: public-css-archive@w3.org
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-values-5] Behavior of if(color-scheme():...) in 'color-scheme' == In #10577 we just resolved to add a color-scheme() test to if(). This is trivially cyclic if used in the 'color-scheme' property, of course. We already have a way of reliably detecting and dealing with cycles in if() tests - we track dependencies as we resolve substitution functions, and when a cycle is detected, the thing triggering the cycle substitutes as a guaranteed-invalid value instead. But we also have a precedent for dealing with cycles caused by using property-dependent values in those properties: an 'em' used in 'font-size' resolves based on the parent font-size instead. If applied here, this would allow the behavior of having an element use the opposite color-scheme of its parent. I'm inclined to keep to the existing precedent that `if()` (and other substitution functions) use, where a cycle is simply invalid. An `if()` that queries the `--foo` property *in* the `--foo` property doesn't look at the parent's `--foo`, it just fails, and I think consistency in this manner is more important. The behavior of using the opposite color scheme to your parent can be achieved using a CQ, since we also resolved to add a color-scheme() test to CQs. (I also think this isn't an *important* use-case to worry about. Pages virtually always want to use *consistent* color schemes; the point of the color-scheme() test is to let you easily do inline branching a la `light-dark()`, but for arbitrary values. If it's *possible* to invert your parent's color scheme, great, but if it's *not possible* (without JS or something) I think it's perfectly fine.) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12851 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 17:15:18 UTC