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?