Overview of CSS Custom Properties syntax, their abilities and use cases.

A practical guidance of the different approaches of using CSS variables, interaction with JavaScript and migration options.

In my previous article CSS custom properties (variables) In-Depth I described CSS custom properties (variables) and variations of their usages.

If you started thinking to move from CSS preprocessors to plain CSS after that- next your question might be: “what about mixins”?

And voilà- there is not only an editor’s draft- https://tabatkins.github.io/specs/css-apply-rule/

but even working implementation in Chrome- https://www.chromestatus.com/feature/5753701012602880

Before continuing reading, make sure you understand the terms of CSS custom properties and CSS mixins.

I thought to start from explaining the purpose of having variables in CSS but actually popularity of CSS pre/postprocessors already did that.

Couple examples:

• color variables for branding
• consistent components properties (layout, positioning etc.)
• avoid code duplications

Yes, of course, you still can search and find/replace all you need manually in your codebase but it’s like not having variables in JS- pain. Having dynamic and scoped CSS variables provides even more abilities for your experiments and applications- you can read, set and update them on the fly! Also you can prevent code duplications around your codebase as recently Webkit guys did in their Web Inspector.

And finally you have an interface to easily pass data from CSS to JS (for example media breakpoint values).

Here is the short-list of features CSS properties have:

• they are dynamic and can be changed at runtime
• they are easily to read/write from JS
• they inherit, cascade and have scopes

So let’s dive deeper what CSS properties are and how to use them.

The idea

Once I needed to add component to show controls like the following:

The number of sections in it had to be configurable. To do it usually you can add two config variables: one in Sass, one in JavaScript.

But I wanted to have config only in one place and reuse it in the second. That’s how the idea to pass data from Sass to JavaScript came to me.

Demo

When you have big project with many files and dependencies, usually you should care about good code base and periodic cleaning / refactoring. The same situation I had when decided to refactor SCSS files- structure, naming and variables…

I was surprised when figured out- there aren’t good instruments to find unused SCSS variables.

The ways they appear is usual:

• somebody removed use of variable but forgot to delete declaration
• it was used for declaration of another variable or inside some expression
• someone added it "for future" or decided to use variable later
• etc.