Re: [csswg-drafts] [css-conditional] `@supports-condition`, for larger feature queries and named reuse (#12622)

The CSS Working Group just discussed ``[css-conditional] `@supports-condition`, for larger feature queries and named reuse``, and agreed to the following:

* `RESOLVED: Use @supports (--foo) for custom supports conditions.`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> lea: Specific grammar questions from @cdoublev<br>
&lt;TabAtkins> here we go https://github.com/w3c/csswg-drafts/issues/12622#issuecomment-3435923624<br>
&lt;fantasai> lea: Sebastian added to the discussion here...<br>
&lt;fantasai> lea: Ideally Sebastian presents this?<br>
&lt;fantasai> TabAtkins: I think I can present this one now.<br>
&lt;fantasai> TabAtkins: Like Lea said, question is how do you refer to a custom supports condition in an @supports rule?<br>
&lt;fantasai> TabAtkins: 2 possibilities<br>
&lt;TabAtkins> whether it's (--foo)<br>
&lt;fantasai> TabAtkins: 1. Parenthesize it, but use dashed-ident.<br>
&lt;TabAtkins> condition(--foo)<br>
&lt;fantasai> TabAtkins: 2. Define a new query function, which takes the name of the condition.<br>
&lt;lea> q+<br>
&lt;Rossen> style {<br>
&lt;Rossen>   @supports-condition --name { @font-face {} }<br>
&lt;Rossen>   @supports (--name) {} /* evaluates to false even if @font-face is supported */<br>
&lt;Rossen> }<br>
&lt;fantasai> TabAtkins: I think that example is asking questions about nesting.<br>
&lt;fantasai> TabAtkins: Question is about how to refer to it in the supports rule.<br>
&lt;fantasai> TabAtkins: Concern with taking the name directly in parens is that it will prevent us from using that exact syntax for testing whether a property name is supported at all<br>
&lt;fantasai> TabAtkins: Other syntax we have is (property: values)<br>
&lt;fantasai> TabAtkins: We intentionally didn't add (property) to @supports so that we engage the CSS parser and get a true result<br>
&lt;fantasai> TabAtkins: Not a separately (and likely brokenly) maintained list in the browser<br>
&lt;fantasai> TabAtkins: So I think using bare name is fine here.<br>
&lt;fantasai> TabAtkins: Function is also fine with me, but more typing<br>
&lt;Rossen> ack lea<br>
&lt;fantasai> lea: Not a strong position either. Concerned about function vs custom media queries, which use bare idents<br>
&lt;fantasai> lea: Also question about nesting and how do multiple rules combine or what<br>
&lt;fantasai> lea: I cannot see a use case with wanting to interleave with regular elements, usually you define up front and then use<br>
&lt;fantasai> lea: I don't see what you might want to detect around bare idents<br>
&lt;fantasai> lea: Already a way to detect custom properties, though I can see why it feels too similar<br>
&lt;Rossen> ack fantasai<br>
&lt;TabAtkins> @media (--foo)<br>
&lt;fantasai> fantasai: Beign consistent with MQ makes sense to me.<br>
&lt;fantasai> s/Beign/Being/<br>
&lt;fantasai> dbaron: Fine with this, but if we take this syntax in @supports rules then we'll also take this anywhere a declaration can be used<br>
&lt;fantasai> dbaron: So as long as we're ok saying "we're not going to allow single custom keyword in places where you write property-value pairs" then this is fine. But that's a slightly bigger reservation of syntax than what some people are talkinga bout.<br>
&lt;Rossen> ack dbaron<br>
&lt;fantasai> TabAtkins: you mean inside a style rule?<br>
&lt;fantasai> dbaron: Yeah<br>
&lt;fantasai> TabAtkins: We are using at-rules for that, so I think it's OK.<br>
&lt;TabAtkins> fantasai: because we ahve custom idents for custom properties... and just dropping the value of the custom prop woudl be subtle for a new feature, it's probably okay to resolve that we won't do that<br>
&lt;TabAtkins> fantasai: and the consistency with MQs is a pretty strong argument for doing this, if we don't have strong reservations agaisnt it<br>
&lt;fantasai> PROPOSED: Use @supports (--foo) for custom supports conditions.<br>
&lt;fantasai> RESOLVED: Use @supports (--foo) for custom supports conditions.<br>
&lt;Rossen> ack fantasai<br>
&lt;fantasai> fantasai: Lea brought up questions about how to handle multiple rules with the same name, etc. Are we tackling those questions here also?<br>
&lt;fantasai> TabAtkins: Relying on last wins.<br>
</details>


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


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

Received on Wednesday, 25 March 2026 16:49:39 UTC