Unconditional Love for Conditional CSS

(Re-published from the Smashing Magazine newsletter.)

I don’t know if you’ve noticed it. It certainly snuck up on me. Somehow at some point in time, CSS got smart. Like really, really smart. The language for styling the web with a quirky cascade is evolving from a standard paintbrush into a full-fledged design application.

The shift is significant, but not totally unexpected. CSS has always been quite smart. The Cascade itself is an elaborate algorithm that evaluates styles and conditionally applies them to elements based on the best “match”. Selectors, after all, are conditional statements.

It took a long time for that to click with me. For the longest time, I treated my work as if my only duty was to select and style. Select, style. Select, style. Select, sty…

My posture never really changed, that is, until I had an epiphany: everything in CSS is relative. We have rem units that are relative to root’s font-size, em units relative to that of an element’s parent container, and even px units relative to nothing but themselves, among many other features that depend on the relationship between elements. It took me years to get there — mind you, I began writing CSS in 2003.

But CSS is more than relative; it’s conditional. There’s a significant distinction between the two as relativity is all about context while conditional behavior is logical. Sure, it may not follow your personal line of logic, but CSS is logical.

That’s what you’ll find in this edition of the newsletter. CSS is only getting smarter and more logical and we’ve seen the best examples of that with CSS features that have shipped over the past year. We’re rounding up several of those features not only to offer a set of CSS specifications but also to help paint a more complete illustration of just how smart CSS is becoming in modern web development.

Inline Conditional if() Statements

The CSS Working Group resolved to press forward with adding an if() function to the CSS Values Module Level 5 specification that would apply styles to elements conditionally based on a certain condition. I wrote about it last week but Lea Verou is leading the push and has a couple of incredibly helpful posts for understanding how the if() function might work and the workarounds we’ve been using that the function could abstract away.

Custom Functions

No, no, not the everyday functions that serve some sort of single purpose, like calc(), min(), max() and whatnot, but custom functions that are more like custom properties… but way more advanced.

What makes custom functions a level up from custom properties is that they act like a custom property contained in a var() but the type check happens after computation. This allows for more complex statements that we can wrap in a new @function rule that contains a condition and the expected result. This is pulled straight from the very early draft illustrating how we can calculate the area of a circle in a custom function:

@function --circle-area(--r) {
  result: calc(pi * var(--r2));
  --r2: var(--r) * var(--r);
}

That’s great in that we can keep logic separate from style rules, whereas today we often perform calculations directly in style rules.

CSS Mixins

If you had clicked through to the draft specification for custom functions, you may have noticed that the draft is titled “CSS Functions and Mixins” — meaning we’re dealing with two new feature proposals. The draft’s URL slug is even /css-mixins despite the lack of a “mixin” definition.

You may be fairly familiar with mixins if you’ve written CSS with a preprocessor, such as Sass, PostCSS, or Less. The CSS version is fairly similar to those implementations, though more CSS-y. Where @function allows us to produce an expected value represented by a custom property, @mixin is designed to return expected style declarations for making certain sets of styles reusable according to the DRY principle. Miriam Suzanne (who recently joined us for a Smashing Hour!) is an editor on the spec draft and has published a thorough explainer of the ideas and goals for both mixins and functions.

Container (and Style) Queries

You’ve likely heard a bunch about CSS Container Queries. There’s already great information about them published on Smashing Magazine, including deep explanations of what they are and their use cases. Container queries even enjoy an excellent level of browser support to date.

But have you heard about Container Style Queries? They are born from the same CSS Containment Module Level 3 specification, but style queries are still in the works. When style queries officially ship (I I believe they will), we’ll have yet another new way to apply styles conditionally.

What exactly is a style query good for? Juan Diego Rodriguez recently explored that question and came up a little empty-handed, but also sees style queries as less a feature than it is part of a much bigger vision about the future of CSS — a vision where style queries are needed for the type of logic we’ve covered throughout this newsletter. Juan’s article is a great one for wrapping your head around the concept, as is Miriam’s comment on the article clarifying key concepts.

Transition to auto

OK, so this isn’t exactly a new “conditional” CSS feature, but it’s one that many of us have wanted for over a decade and it’s additional proof that the future of CSS is just plain smarter than where it’s been in the past.

Here’s the scoop: A new calc-size() function is being used to experiment with an approach to determine the size of auto even when we have no idea what auto equals — which is always the case unless we explicitly declare fixed-size dimensions on an element. We’ve never been able to transition an element from, say, height: 0 to height: auto (or vice versa) because auto is an unknown value before computation happens.

Declaring calc-size(auto) fixes that. We can supply it with just a vague keyword about an element’s dimensions — calc-size(auto) — to go from a fixed value to the element’s intrinsic size and back. This is all very experimental (only Chrome Canary for now) and likely to change before it becomes an official feature, but how neat is it that CSS is getting to the point where it understands what certain keywords evaluate to before they’re evaluated?

Check out Chris Coyier’s early look at the idea.