“If” CSS Will get Inline Conditionals

Just a few sirens went off a few weeks in the past when the CSS Working Group (CSSWG) resolved so as to add an if() conditional to the CSS Values Module Degree 5 specification. It was Lea Verou’s X submit that very same day that caught my consideration:

A historic day for CSS 😀🎉

Should you write any elements used and/or styled by others, you know the way enormous that is!

background: if(model(–variant: success), var(–inexperienced));

Even when you don’t, this can enable issues like:
padding: if(var(–2xl), 1em, var(–xl) or var(–m),… pic.twitter.com/cXeqwBuXvK

— Lea Verou (@LeaVerou) June 13, 2024

Lea is the one who opened the GitHub concern resulting in the dialogue and in a stroke of coincidence — or serendipity, maybe — the decision got here in on her birthday. That needed to be fairly a whirlwind of a day! What did you get in your birthday? “Oh, you understand, simply an accepted proposal to the CSS spec.” Wild, simply wild.

The accepted proposal is a inexperienced gentle for the CSSWG to work on the concept with the intent of circulating a draft specification for additional enter and concerns en path to, hopefully, change into a advisable CSS function. So, it’s gonna be a sizzling minute earlier than any of that is baked, that’s, if it will get totally baked.

However the thought of making use of types based mostly on a conditional requirement is tremendous thrilling and price an early take a look at the concept. I scribbled some notes about it on my weblog the identical day Lea posted to X and thought I’d distill these right here for posterity whereas rounding up extra particulars which have come up since then.

This isn’t a brand new thought

Many proposals are born from beforehand rejected proposals and if() is not any totally different. And, certainly, now we have gained a number of CSS options in latest days that enable for conditional styling — :has() and Container Type Queries being two of the extra apparent examples. Lea even cites a 2018 ticket that appears and reads so much just like the accepted proposal.

The distinction?

Type queries had already shipped, and we might merely reference the identical syntax for situations (plus media() and helps() from Tab’s @when proposal) whereas within the 2018 proposal how situations would work was largely undefined.

Lea Verou, “Inline conditionals in CSS?”

I like how Lea factors out that CSS goes on to explain how CSS has all the time been a conditional language:

Of us… CSS had conditionals from the very starting. Each selector is basically a conditional!

Lea Verou, “Inline conditionals in CSS?”

True! The Cascade is the automobile for evaluating selectors and matching them to HTML components on a web page. What if() brings to the desk is a approach to write inline situations with selectors.

Syntax

It boils right down to this:

<if()> = if( <container-query>, [<declaration-value>]{1, 2} )

…the place:

• Values could be nested to supply a number of branches.
• If a 3rd argument will not be offered, it turns into equal to an empty token stream.

All of that is conceptual in the mean time and nothing is about in stone. We’re prone to see issues change because the CSSWG works on the function. However because it at the moment stands, the concept appears to revolve round specifying a situation, and setting one among two declared types — one because the “default” model, and one because the “up to date” model when a match happens.

.aspect {
  background-color:
    /* If the model declares the next customized property: */
    if(model(--variant: success),
      var(--color-green-50), /* Matched situation */
      var(--color-blue-50);  /* Default model */
    );
}

On this case, we’re on the lookout for a model() situation the place a CSS variable known as --variant is asserted and is about to a price of success, and:

• …if --variant is about to success, we set the worth of success to --color-green-50 which is a variable mapped to some greenish shade worth.
• …if --variant will not be set to success, we set the worth of the success to --color-blue-50 which is a variable mapped to some bluish shade worth.

The default model could be non-obligatory, so I feel it may be omitted in some circumstances for barely higher legibility:

.aspect {
  background-color:
    /* If the model declares the next customized property: */
    if(model(--variant: success),
      var(--color-green-50) /* Matched situation */
    );
}

The syntax definition up high mentions that we might assist a 3rd argument along with the matched situation and default model that enables us to nest situations inside situations:

background-color: if(
  model(--variant: success), var(--color-success-60), 
    if(model(--variant: warning), var(--color-warning-60), 
      if(model(--variant: hazard), var(--color-danger-60), 
        if(model(--variant: major), var(--color-primary)
      )
    ),
  )
);

Oomph, appears like some wild inception is occurring in there! Lea goes on to recommend a syntax that will lead to a a lot flatter construction:

<if()> = if( 
  [ <container-query>, [<declaration-value>]{2}  ]#{0, },
  <container-query>, [<declaration-value>]{1, 2} 
)

In different phrases, nested situations are rather more flat as they are often declared outdoors of the preliminary situation. Identical idea as earlier than, however a distinct syntax:

background-color: if(
  model(--variant: success), var(--color-success-60), 
  model(--variant: warning), var(--color-warning-60),
  model(--variant: hazard), var(--color-danger-60), 
  model(--variant: major), var(--color-primary)
);

So, quite than one if() assertion inside one other if() assertion, we will lump all the attainable matching situations right into a single assertion.

That is all associated to model queries

We’re making an attempt to match an if() situation by querying a component’s types. There isn’t a corresponding dimension() perform for querying dimensions — container queries implicitly assume dimension:

.aspect {
  background: var(--color-primary);

  /* Situation */
  @container mother or father (width >= 60ch) {
    /* Utilized types */
    background: var(--color-success-60);
  }
}

And container queries change into model queries after we name the model() perform as a substitute:

.aspect {
  background: orangered;

  /* Situation */
  @container mother or father model(--variant: success) {
    /* Utilized types */
    background: dodgerblue;
  }
}

Type queries make much more sense to me once they’re seen within the context of if(). With out if(), it’s simple to query the final usefulness of fashion queries. However on this gentle, it’s clear that model queries are a part of a a lot greater image that goes past container queries alone.

There’s nonetheless loads of issues to suss out with the if() syntax. For instance, Tab Atkins describes a attainable situation that would result in confusion between what’s the matched situation and default model parameters. So, who is aware of how this all shakes out ultimately!

Circumstances supporting different situations

As we’ve already famous, if() is much from the one kind of conditional test already offered in CSS. What wouldn’t it appear to be to put in writing an inline conditional assertion that checks for different situations, equivalent to @helps and @media?

In code:

background-color: if(
  helps( /* and many others. */ ),
  @media( /* and many others. */ )
);

The problem could be container supporting dimension queries. As talked about earlier, there isn’t a specific dimension() perform; as a substitute it’s extra like an nameless perform.

@andruud has a succinctly describes the problem within the GitHub dialogue:

I don’t see why we couldn’t do helps() and media(), however dimension queries would trigger cycles with structure which are onerous/not possible to even detect. (That’s why we would have liked the restrictions we at the moment have for dimension CQs within the first place.

“Can’t we already do that with [X] strategy?”

Once we had been trying on the syntax earlier, you will have observed that if() is simply as a lot about customized properties as it’s about conditionals. A number of workarounds have emerged over time to imitate what we’d acquire if() we might set a customized property worth conditionally, together with:

• Utilizing customized properties as a Boolean to use types or not relying on whether or not it is the same as 0 or 1. (Ana has a beautiful article on this.)
• Utilizing a placeholder customized property with an empty worth that’s set when one other customized property is about, i.e. “the customized property toggle trick” as Chris describes it.
• Container Type Queries! The issue (moreover lack of implementation) is that containers solely apply types to their descendants, i.e., they can’t apply types to themselves once they meet a sure situation, solely its contents.

Lea will get deep into this in a separate submit titled “Inline conditional statements in CSS, now?” that features a desk that outlines and compares approaches, which I’ll merely paste beneath. The reasons are filled with advanced CSS nerdery however are extraordinarily useful for understanding the necessity for if() and the way it compares to the intelligent “hacks” we’ve used for years.

Glad birthday, Lea!

Belated by two weeks, however thanks for sharing the spoils of your massive day with us! 🎂

References

Direct Hyperlink →