Re: [csswg-drafts] [css-conditional-5] Desugaring @if (#12909)

(The main reason to have `@when` is just to combine the currently disparate query constructs together; it's kinda annoying to try and query on both an MQ and an SQ at the same time. This `@if` idea is indeed something completely different.)

This sounds pretty good overall; it definitely saves on typing in some cases vs repeatedly inlining the same `if()` check, as your example shows.

However, I don't like the proposed behavior for nesting style rules inside of `@if`. This is *not* the same issue as `@container`. In `@container`, the element you're querying is *always* an ancestor of the element you're styling, so the rule's position "above/outside" the style rule makes intuitive sense. And if the condition you're testing isn't intercepted by anything, you can do further nested rules and they'll test against the same ancestor; it's a minor footgun to watch out for, but usually not an issue in practice I think.

In your proposed `@if`, that's not at all true - it's always the element itself being tested, which means that nested elements *by definition* evaluate the test against something different. That's super confusing, imo; testing a non-inherited custom property will virtually always cause nested rules to fail for no apparent reason.

So, I think `@if` here should *only* be allowed in a nested context, and then *only* allow declarations, not style rules, inside of itself. (Plus at-rules, inheriting the same context restriction, so you can stack `@if`s, and even mix it with `@media` or whatever.)

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


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

Received on Monday, 13 October 2025 22:12:58 UTC