[css-conditional-5] Desugaring @if

@tabatkins

With inline if() and revert-rule now in place, do we indeed¹ have everything we need to add a useful block-if?

Just like how @container imposes an additional "late" (vs MQs) condition on rules, we could use similar behavior for @if:

@container (width > 800px) {
  .thing { font-size: 30px; }
}

The above effectively behaves as²:

.thing { font-size: if(container(width > 800px):30px; else:revert-rule); }

@if could work the same way:

@if style(--mode:pill) {
  .box { border-radius: 10px; }
}

Desugared:

.box { border-radius: if(style(--mode:pill):10px; else:revert-rule); }

Obviously it would work with nesting, so you can set a bunch of things conditionally in a nice way:

.box {
  @if style(--mode:pill) {
    border-radius: 10px;
    background-color: tomato;
    padding: 4px;
  }
}

This "inlinification" should answer questions about cycles (etc) automatically. I wouldn't expect implementations to literally perform this, of course. It's just a way of explaining the behavior from existing primitives.

Multiple levels of @if would desugar into a compound if-test:

@if style(--mode:pill) {
  @if style(--theme:dark) {
    .box { border-radius: 10px; }
  }
}

Desugared:

.box { border-radius: if(style(--mode:pill) and style(--theme:dark):10px; else:revert-rule); }

There might be a potential trap when using nesting, e.g. authors could reasonably expect the following if-test to branch off of <div class=box>'s variables, when in reality style(--mode:pill) gets evaluated against <div class=inner>'s variables:

.box {
  @if style(--mode:pill) {
    .inner { green: green; }
  }
}

However, this is similar to how different rules within a single @container rule can target totally different containers based on the element being matched.

Thoughts on this? E.g. @tabatkins, @LeaVerou?

See Pave the cowpaths for block @if in https://github.com/w3c/csswg-drafts/issues/12806 ↩
Using the proposed container() test from https://github.com/w3c/csswg-drafts/issues/12069. ↩

Duplicate of @when

Not a duplicate of @when. That just combines the existing @media and @supports queries into one. As proposed here, @if can query custom properties on the subject element itself, which requires a totally different model. EDIT: Forgot to say: if we adopt this, we may not actually need @when, though.

(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 @ifs, and even mix it with @media or whatever.)

@tabatkins

Yup, a block @if has always been my plan when proposing if() and revert-rule — they are its building blocks to pave the way.

My original idea was that for descendants you can use regular style queries (which would alleviate @tabatkins' concern), but I don't think that can be determined at parse time. I wonder if we can have it late-resolve depending on what the nested rule is targeting.

Nested rules should definitely not be evaluating a different condition, but that just affects how we define the desugaring. E.g. we could define that it desugars the condition to a <boolean> custom property¹ and then all if()s use that custom property instead of the condition verbatim.

And add <boolean> as type for custom properties, obvs 😁 ↩

nesting style rules inside of @if [... is] super confusing, imo

Agree.

So, I think @if here should only be allowed in a nested context, and then only allow declarations, not style rules, inside of itself.

That would be ideal.

E.g. we could define that it desugars the condition to a custom property and then all if()s use that custom property instead of the condition verbatim.

That would indeed be neat. It would be like implicitly generating a style-container-query for it.

As an example:

.box {
  @if style(--x: pill) {
     & .inner {
       border-radius: 5px;
     }
  }
}

Effectively means:

.box {
  --unobservable-prop: if(style(--x:pill): true; else: false);

  & .inner {
    border-radius: if(style(--unobservable-prop: true); else: revert-rule);
  }
}

Unfortunately nesting isn't "DOM-structural" like that, so we have no guarantee that the outer thing actually is an ancestor of the inner things. It breaks down as soon as you use e.g. sibling selectors, .box { @if(...) { & + .thing { } } }.

@scope is structural, so your trick should work directly beneath that rule:

@scope (.box) {
  @if style(--x: pill) {
     & .inner {
       border-radius: 5px;
     }
     & + .thing { /* Out of scope anyway */
        color: red;
     }
  }
}

In any case, I would restrict @if to declarations-only in the first version, if possible.

@andruud

Yeah, the lack of auto-scoping makes any desugaring approach unworkable. (We'll have the same problem with Mixins, fwiw; @andruud and I were chatting about this off-list today.)

Saw a wish about this on Mastodon today: https://front-end.social/@matuzo/115617707314652734

While declarations-only at the beginning would be ok-ish, if we were able to come up with how to handle nested rules — it would be much-much better and less confusing for authors who would for sure try nesting stuff only to find it not working.

I think it is sensible to just disallow styling anything outside the “scope” of the topmost parent selector, so & + .thing not doing anything is totally fine from an author's perspective. I imagine, the problem is more how to desugar it? Can we detect that some rules target elements outside the “parent” scope and throw them away?

What if @if was defined to basically have similar semantics as @scope? Something like

@if style(--x: pill) on (.button) {

}

Yeah, we can already do:

.foo {
  @scope (&) { } /* Scoped according to the parent rule */
}

So @if() can just implicitly do something similar. "Throwing away" rules that are outside the scope then means those rules never match per @scope's already-defined behavior. As discussed in #13113, we'll probably want to avoid adding proximity or changing specificity here, though.

This proposal is also quite crucial for mixins.

It's currently annoying to have an enum argument and then have a switch or if/elseif chain over that enum and emit totally different styles.

e.g.

@mixin --icon(--name) {
  @if (style(--name: circle)) {
    size: 10px;
    background-image: url(circle.svg);
    /* ... */
  }

  @if (style(--name: star)) {
    size: 10px;
    mask-image: url(star.svg);
    background-color: pink;
    /* ... */
  }
}

The ; else:revert-rule trick might work fine, but it isn't intuitive :)

Navigation Menu

Repository navigation

[css-conditional-5] Desugaring @if #12909

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-conditional-5] Desugaring @if #12909

Description

Footnotes

Activity

otomad commented on Oct 9, 2025

andruud commented on Oct 10, 2025

tabatkins commented on Oct 13, 2025

LeaVerou commented on Oct 14, 2025

Footnotes

andruud commented on Oct 14, 2025

tabatkins commented on Oct 14, 2025

kizu commented on Nov 26, 2025

LeaVerou commented on Nov 26, 2025

andruud commented on Nov 26, 2025

romainmenke commented on Oct 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions