- From: Guillaume via GitHub <noreply@w3.org>
- Date: Fri, 24 Oct 2025 07:32:10 +0000
- To: public-css-archive@w3.org
cdoublev has just created a new issue for https://github.com/w3c/csswg-drafts:
== [css-conditional] Better `<supports-condition>` syntax ==
The main motivations are to accept all support features in `supports()` and prevent (almost) any invalid argument from making its context invalid ([`if()`](https://drafts.csswg.org/css-values-5/#funcdef-if), [`@when`](https://drafts.csswg.org/css-conditional-5/#at-ruledef-when), [`@import`](https://drafts.csswg.org/css-cascade-4/#at-ruledef-import)).
`@supports` prelude is defined with [`<supports-condition>`](https://drafts.csswg.org/css-conditional-3/#typedef-supports-condition), therefore it accepts (almost) any value wrapped in parens. `supports()` takes `<supports-condition>` but also other values that can make it invalid, like `supports(garbage)`.
The current (simplified) syntax is:
```
<supports-in-parens> = (<supports-condition>) | <supports-feature> | <general-enclosed>
<supports-feature> = (<declaration> | <extension-name>)
| at-rule(<at-keyword-token>)
| font-format(<font-format>)
| font-tech(<font-tech>)
| selector(<complex-selector>)
<supports()> = supports(<supports-condition> | <declaration>)
```
The suggested syntax:
```
<supports-in-parens> = (<supports-condition> | <supports-feature>)
<supports-feature> = <declaration>
| <extension-name>
| at-rule(<at-keyword-token>)
| font-format(<font-format>)
| font-tech(<font-tech>)
| selector(<complex-selector>)
| <any-value>
<supports()> = supports(<supports-condition> | <supports-feature>)
```
Related: #12903.
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13012 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 24 October 2025 07:32:11 UTC