- 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