Re: [csswg-drafts] [css-values-5] Allow `if()` in descriptors (#11941)

The CSS Working Group just discussed ``[css-values-5] Allow `if()` in descriptors``, and agreed to the following:

* `RESOLVED: Work on this in the next level (in consideration of all the complications outlined above).`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> TabAtkins: We have if() function which allows conditional tests. But only works in properties, because substitution functions are only defined in that context<br>
&lt;fantasai> TabAtkins: but there are good use cases for being able to use if() with global tests like MQ<br>
&lt;fantasai> TabAtkins: It could be done by using conditional at-rules today<br>
&lt;lea> q?<br>
&lt;fantasai> TabAtkins: if() is a nice syntactic convenience.<br>
&lt;fantasai> TabAtkins: Anders says it's doable as long  as we're clear which tests can be used outside an element ocntext<br>
&lt;fantasai> TabAtkins: I agree, should be useful. Right now just style query and color scheme query that we'd have to turn off. But doable<br>
&lt;fantasai> TabAtkins: So I suggest we accept this feature, spec text TBD<br>
&lt;lea> +1, many upsides, little to no downsides<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: I think it makes sense, but rather than excluding we should use an allowlist<br>
&lt;emilio> q+<br>
&lt;TabAtkins> TabAtkins: agree<br>
&lt;lea> q+<br>
&lt;TabAtkins> fantasai: like there's a lot of variable stuff we can't do outside of an element context<br>
&lt;astearns> ack emilio<br>
&lt;fantasai> emilio: relatedly, there might be descriptors (e.g. @font-face) ...<br>
&lt;fantasai> emilio: even in the case in the OP, @font-face is exposed to the FontFace API<br>
&lt;fantasai> emilio: It's fairly different from media case<br>
&lt;fantasai> emilio: I'm not sure how we should expose these values when you ask for them<br>
&lt;fantasai> emilio: Seems weird to do the substitution when you do the getter<br>
&lt;fantasai> emilio: requires updating style information, it's a bit annoying<br>
&lt;fantasai> TabAtkins: currently those return strings<br>
&lt;fantasai> TabAtkins: so I think it's fine?<br>
&lt;fantasai> TabAtkins: we'd have to define how substitutions are reflected<br>
&lt;fantasai> TabAtkins: and I think it's fine to say that the OM doesn't reflect substitutions<br>
&lt;fantasai> emilio: That means the programmatic functions need to accept these, and those are exposed to workers, which is annoying<br>
&lt;fantasai> emilio: There's a lot of edge cases to think about<br>
&lt;fantasai> emilio: And that's just the @font-face ones<br>
&lt;fantasai> emilio: And then @page stuff might affect MQ?<br>
&lt;fantasai> astearns: So seems useful thing, but complications to work through.<br>
&lt;astearns> ack lea<br>
&lt;fantasai> lea: Do we need to exclude variables syntactically?<br>
&lt;fantasai> lea: Could define that variables resolve to their initial value.<br>
&lt;fantasai> lea: idk if web compatible<br>
&lt;fantasai> lea: but as an author, that's what I would expect<br>
&lt;fantasai> TabAtkins: I would say that those tests, not on allow list, would just resolve to false<br>
&lt;fantasai> TabAtkins: that would potentially allow us to turn on some tests in the future<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: given all that, I think we should maybe defer this to later... I don't want us to spend tons of times going down the rabbit holes and delaying if() on elements<br>
&lt;TabAtkins> fantasai: so maybe say this is a good idea, but for the next level. sounds like it'll be a bunch of work on the spec and impl side, for something that is technically doable right now in other ways<br>
&lt;emilio> +1<br>
&lt;TabAtkins> fantasai: so I worry if we batch it all together it'll be slower to get the core feature interoperable<br>
&lt;TabAtkins> astearns: so we could resolve to accept it but punt to the next level. no more delay needed<br>
&lt;TabAtkins> astearns: agree we shoudln't gate the existing if() on this<br>
&lt;TabAtkins> +1<br>
&lt;fantasai> PROPOSED: Work on this in the next level.<br>
&lt;fantasai> RESOLVED: Work on this in the next level (in consideration of all the complications outlined above).<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11941#issuecomment-3329498991 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:36:09 UTC