[csswg-drafts] [css-conditional] `@supports-condition`, for larger syntax and reuse (#12622)

LeaVerou has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-conditional] `@supports-condition`, for larger syntax and reuse ==
Originally, `@supports` only took a nice `(property: value)` query that looked exactly like the declaration being queried. Over time, we started expanding it to a parallel CSS meta-syntax, with `selector()` and now `at-rule()` referring to at-rules separate from their actual syntax, creating issues such as #6966 or #11118.

This got me thinking: it would be nice if authors could basically stuff the thing they want to detect _somewhere_ without having to know or care what type of CSS syntax it is and how to query support in `@supports`.

What if we had an at-rule that could be used to store and reference conditions, and can accept any parse-able CSS syntax? It can then be used naked in `@supports` and resolves to `true` if the rules nested within the `@supports-condition` rule do not produce any parse errors.
Direct manipulation over indirection.

CSS grammar is already defined to have robust-enough parsing that it can handle parsing unknown structures, so this should be doable syntactically.

It would be defined as a nested at-rule, that can accept declarations or rules, so it would work like this:

Raw declaration:
```css
@supports-condition --masonry-h {
 display: grid-stack;
 item-direction: row;
} 

/* Equivalent to (display: grid-stack) and (item-direction: row) */
@supports --masonry-h {
 /* stuff */
}
```

More natural syntax for `selector()`:
```css
@supports-condition --part-v2 {
 &::part(foo):hover,
 &::part(bar)::before:hover {
 }
}

/* Like @supports selector(&::part(foo):hover, &::part(bar)::before:hover) */
@supports --part-v2 {
 /* stuff */
}
```

More natural syntax for `at-rule()` (addressing #11118)

```css
@supports-condition --page-margin {
 @page {
  margin: 0;
  @top-right {
      margin: 0;
    }
 }
}
```

This also means that we can instantly test the entirety of CSS, with dedicated `@supports` functions needed only for things that do parse correctly. E.g. `font-tech()` would still be necessary.

And this feeds two birds with one scone: it solves the problem of "how do we use `@supports` to query XYZ?" *and* also provides a reuse mechanism!
It almost seems too good to be true, so I wonder if it's feasible implementation-wise to get parse error info for a larger structure like this as a whole.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12622 using your GitHub account


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

Received on Tuesday, 19 August 2025 12:52:46 UTC