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

@tabatkins 

> > but that means we can never use `(foo)` to mean "does this property exist?", which is inconsistent with how style() conditions work.
> 
> We super intentionally didn't allow that syntax in `@supports` from the beginning, so I'm fine with continuing to deny that as a possibility.

Even if we never do this, I don't want to introduce syntax that makes it impossible to ever change our mind.
Also, there is already the precedent from `style()` conditions where both `style(foo: bar)` and `style(foo)` are allowed, so it would introduce an inconsistency.

@kbabbitt Excellent points!

> 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.

I don't think we need that. JS already has many reuse mechanisms — just create a variable. All we need is a method where you can pass arbitrary CSS as a string. If we can't overload the single argument `CSS.supports()`, then I guess we need a new method (e.g. `CSS.isvalid()` or `CSS.canParse()`).

Named conditions _already_ defined in CSS should probably work though.

> 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:
> 
> @import "a.css" supports(--condition-a); /* defines --condition-b */
> @import "b.css" supports(--condition-b); /* defines --condition-a */

That's probably the hairiest issue raised so far.

I can see the following solutions, none ideal:

- Allow `@supports-condition` before `@import` — I suspect that won't fly
- Defer loading until the corresponding `@supports-condition` is encountered, _unless_ it's already defined (e.g. by a previous `@import`). Then it's up to authors to make sure they define their conditions before their imports.


-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12622#issuecomment-3204774982 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 08:14:57 UTC