- From: andruud via GitHub <noreply@w3.org>
- Date: Tue, 07 Oct 2025 20:23:42 +0000
- To: public-css-archive@w3.org
andruud has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-conditional-5] Desugaring @if == With inline [if()](https://drafts.csswg.org/css-values-5/#if-notation) and [revert-rule](https://github.com/w3c/csswg-drafts/issues/10443#issuecomment-2627865962) now in place, do we indeed[^1] 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`: ```css @container (width > 800px) { .thing { font-size: 30px; } } ``` The above effectively behaves as[^2]: ```css .thing { font-size: if(container(width > 800px):30px; else:revert-rule); } ``` `@if` could work the same way: ```css @if style(--mode:pill) { .box { border-radius: 10px; } } ``` Desugared: ```css .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: ```css .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: ```css @if style(--mode:pill) { @if style(--theme:dark) { .box { border-radius: 10px; } } } ``` Desugared: ```css .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: ```css .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? [^1]: See `Pave the cowpaths for block @if` in https://github.com/w3c/csswg-drafts/issues/12806 [^2]: Using the proposed `container()` test from https://github.com/w3c/csswg-drafts/issues/12069. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12909 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 7 October 2025 20:23:43 UTC