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

I see a couple of different ideas here which might be worth decoupling and considering separately:

1. Feature-querying arbitrary CSS. That certainly seems useful and worth exploring to me. I'd want to do some prototyping to confirm, but my sense is that implementation would just require extra instrumentation in existing CSS parsers.

2. Taking feature queries out of line from `@supports` and assigning them names. I can see the use cases and like the idea in principle, but I have reservations about practicalities related to the other places feature queries can be used:

a. The `CSS.supports` method. I think it's fine on its face to pass a named feature query here. However, if named queries were the only way to feature-query at-rules (or arbitrary CSS), then an author writing a `CSS.supports` call in script would need to define a named feature query somewhere else in CSS on their page, which would be bad for code locality if they didn't otherwise want to do that. One way to solve this would be to introduce a new method on `CSS` which takes a feature query string as a parameter.

b. `@import "style.css" supports(...)`. Presumably we'd need to defer making a decision on whether to actually load the imported CSS until we finish parsing everything else and discover what the named feature query means. That seems not great, but maybe it's okay. Though it might be possible to create weird cyclic behavior with something like:

```css
@import "a.css" supports(--condition-a); /* defines --condition-b */
@import "b.css" supports(--condition-b); /* defines --condition-a */
```


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


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

Received on Wednesday, 20 August 2025 06:58:23 UTC