Maybe you’ve heard it: There’s a new game in town. The town being CSS and the game is called variables. For a while, the only options to make CSS more manageable with the help of variables were SASS and LESS, which do have subtle differences in how they handle variables, but essentially do the same thing. Now most modern browsers (except IE) support variables in the form of CSS custom properties.

So what does that mean for CSS architecture? Do you have to migrate to the new variable format from your trusted SASS variables or is a new preprocessor like CSS Next the answer to this situation?

To answer this question, you have to understand that SASS variables and CSS custom properties live in very different worlds which give them different possibilities: SASS variables are replaced with their values as the preprocessor produces its CSS output long before the browser interprets the code, while CSS custom properties are evaluated by the browser at runtime.

And while SASS variables closely model the syntax you might be used from traditional programming languages, CSS custom properties introduce a new syntax which frankly is as awkward as their title: each variable has to start with a double dash and for a variable to be evaluated it needs to be wrapped in var(), comparable to how attr() works with data-attributes:

:root {
--my-blue: #00f;
}

.button {
background-color: var(--my-blue);
}

In the example, the variable is set in the root scope, which cascades down into every element, but can be overwritten along the way. So if you redefine the variable --my-blue in .button, <button class="button"></button> and all its children will use the new value. Here lies a major difference to SASS variables, which have no knowledge of the DOM-tree whatsoever.

Also, media-queries can override the default root scope, which allows for very powerful changes at a breakpoint. For example, increasing the default paddings of a lot of modules for bigger screens at once – or changing a lot of font-sizes depending on the screen size. Both of these changes are possible without CSS custom properties, but they result in a large number of media queries, if a lot of different modules need to be changed. Now all that needs to be modified is one variable:

See the Pen Responsive CSS Custom Properties by Bjorn Ganslandt (@Ansimorph) on CodePen.

Similarly, theming is possible with the current CSS tools, but poses a big architectural challenge: If SASS is being used for theming, it makes real-time previews very difficult, because the code has to be preprocessed on a server, or a lot of CSS needs to be overwritten with theme-specific classes, making the code hard to maintain. CSS variables allow for themes that are easy to maintain, and that can be previewed by a user in real time with minimal effort.

The drawback of evaluation in the browser is that SASS can not do anything to variables such as --my-blue. No lighten function or mixin can access the value that will fill the variable at runtime, because is it unknown while preprocessing. This means that manipulations of the CSS Custom Property are limited to calc, which is not much, once you’re used to the functionality SASS provides. Eventually, CSS will get its own color() function, but even then CSS will be no match for the functionality and readability of SASS.

Where do PostCSS and CSS Next come into all of this? CSS Next is built on top of PostCSS to allow the usage of future CSS syntax, which it transpiles into CSS that current browsers understand. This includes both the color() function, and CSS custom properties. It is however bound to the same limitations as SASS, because its output is plain CSS without any knowledge of the DOM or changes at runtime. So CSS Next allows you to use CSS custom properties today in all browsers, but it removes the aspects that make them truly interesting, leaving only the new syntax.

Understanding the strengths and weaknesses of SASS variables allows to decide when to use which technology. If your project requires dynamic theming, CSS custom properties will be the way to go very shortly. Otherwise, SASS variables are still a good choice, because they give you access to the power of a wide range of SASS functions. Since the two techniques are by no means exclusive, dynamic variables can be fed with content from SASS variables allowing you to sprinkle dynamic magic throughout your project – comparable to currentColor which also lives happily in many SASS projects.

CSS Next is currently only a good solution if you want to get used to the syntax. Given how long the combination of CSS custom properties and functions tend to get, I can imagine that even when CSS has caught up with SASS in terms of functionality, some syntactic sugar will still be in high demand. And I will not be surprised if PostCSS provides that sugar in the future.