CSS if() — breakthrough or breakdown? — Blog

What does `if()` actually do?

The if() function lets you assign property values based on conditions. It lives right inside the value — conceptually closer to a ternary operator than to a full-blown if statement in programming languages.

First kind of condition — style queries

If the custom property --scheme equals dark, the background becomes gray:

body {
  --scheme: dark;

  background: if(
    style(--scheme: dark): gray;
  );
}

If the value is different, the function resolves to Guaranteed-invalid value (effectively the same as initial).

body {
  --scheme: color;

  background: if(
    style(--scheme: dark): gray;
  );
}

The regular cascade just skips a broken declaration and keeps the previous value. if(), on the other hand, resets the property entirely — as if you’d explicitly written initial.

You can add another condition to handle a new value:

body {
  --scheme: color;

  background: if(
    style(--scheme: dark): gray;
    style(--scheme: color): lightblue;
  );
}

And if nothing matches — there’s always an else branch, just like in “real” programming languages:

body {
  --scheme: other;

  background: if(
    style(--scheme: dark): gray;
    style(--scheme: color): lightblue;
    else: tomato;
  );
}

Second kind — media queries

The function also works with media expressions:

h1 {
  font-size: if(
    media(width > 700px): 72px;
    else: 42px;
  );
}

If the viewport is wider than 700 px — you get a big, bold heading. Otherwise, it stays smaller.

Third kind — feature queries

if() also supports feature queries. For example, you can set a red text color if the element() function isn’t supported:

h1 {
  color: if(
    not supports(element("#myid")): red;
    else: white;
  );
}

If you only need to tweak a single value — if() looks neat and concise.

But let’s be honest — everything we’ve seen so far could be done before, just differently.

Do we really need it?

The same checks can be done using plain directives: @container, @media, and @supports. The behavior is identical:

:root {
  --scheme: other;
}

body {
  background: tomato;
}

@container style(--scheme: dark) {
  body { background: gray; }
}

@container style(--scheme: color) {
  body { background: lightblue; }
}

@media (width > 700px) {
  h1 { font-size: 72px; }
}

@supports not (element("#myid")) {
  h1 { color: red; }
}

@supports (width: calc(1px * sibling-count())) {
  h1 { background-color: white; }
}

In short: if() doesn’t introduce new logic. It’s pure syntactic sugar that brings existing query mechanisms down to the value level.

At first, if()-based code looks more compact. But that’s true only when you’re changing a single property — which, frankly, is pretty rare.

Not quite what we imagined

When you hear about a “real if in CSS”, you imagine comparing variables and triggering different sets of properties right inside a CSS rule:

.compare-numbers {
  --a: 5;
  --b: 10;

  if (var(--a) > var(--b)) {
    width: 100px;
    height: 200px;
  } else {
    width: 250px;
    height: 150px;
  }
}

The reality turned out much simpler: if() works only inside a single property value — no comparison operators, no multiple variables, no logic blocks.

Basically, you can only check whether a variable equals a specific value. That’s it:

.selector {
  --a: 5;
  width: if(style(--a: 5): 100px;);
}

In JavaScript, that would look roughly like this:

let a = 5;
let width = (a === 5) ? "100px" : "";

“Imagine if JavaScript had only this kind of powerful conditional logic!”

A glimmer of hope: self queries

But not everything is disappointing.

Here’s the bright side: if() can check not only parent variables (as container style queries do) but also variables defined on the element itself.

For example:

h1 {
  font-size: if(
    style(--size: small): 32px;
    else: 72px;
  );
}

When --size isn’t defined, the else branch triggers (72 px). Add the variable directly to the element — and the condition fires:

h1 {
  --size: small;

  font-size: if(
    style(--size: small): 32px;
    else: 72px;
  );
}

This may look minor, but it’s important: traditional directives like @container only observe parents, while if() can look at itself.

Looking ahead

How could if() evolve?

Add comparison operators: <, >, <=, >=.
Support multiple variable comparisons.
Work on the rule level, not just property values.

Extra operators and variable comparisons are probably next on the roadmap. But lifting if() to the rule level? That’s going to be hard.

Verdict: breakthrough or breakdown?

If if() stays exactly as it is now, it’s a bit of a failure. Put it on your linter’s blacklist and move on — because in its current form, it lets you write the same messy logic as in preprocessors, only natively.

Still, there’s hope. If this experiment keeps evolving, it might become something bigger. The current release isn’t a failure or a triumph — more like a “pre-patch before the major update.”

What does if() actually do?