One thing I find quite quirky is the way everybody uses:root for their "all" selector with CSS variables rather thanhtml . Unless you're using CSS with an XML document (which is pretty rare) all you're achieving is using an unnecessarily high specificity selector. Something that as a general practice is best avoided.

The only reason I can think of for doing that is that's what the specification does, and it does it because it doesn't then have to distinguish between use with HTML and XML documents. And everyone is just then copying from everyone else.

I like CSS variables a lot. As you say, though, their main disadvantage is backwards compatibility. Unfortunately, Internet Explorer is not going to get its act together, as it has been replaced and won't be developed any further. So, the 0.16% of desktop users using IE6 is just a completely lost cause, while for the 6% using another IE version, hope is running dry too.

Anyway, I have used them in two projects. For one, I decided simply not to care too much for users of older browsers. For the other, I was using so much other new(ish) technology that supporting IE didn't make sense anyway.

I like the CSS variables a lot more than the preprocessor variables that I have used. Maybe that was just the circumstances in which they used them, but there are also some nifty tricks that you can do.

For example, there was a project that generally didn't need browser prefixes in its CSS because it was rather recent. But then at one point I needed one. So, this is what I did:

.someclass{--tab-size:4;tab-size:var(--tab-size);-moz-tab-size:var(--tab-size);}

I would never even have come up with that using preprocessor variables, because (a) they're not scoped, so you would need to add a large amount of scope to the variable name and (b) you can't keep them this close to where they matter.

The other thing that sets them apart from preprocessor variables is of course this:

p.colored{color:var(--my-color);}.red{--my-color:red;}.green{--my-color:green;}

which lets you do this:

<pclass="colored red">Red text</p><pclass="colored green">Green text</p>

And even this:

<divclass='red'><pclass='colored'>Red text</p><p>Normal text</p><pclass='colored'>More red text</p></div><divclass='green'><pclass='colored'>Green text</p></div>

Now, this example is a bit contrived and it's not something I see myself using all that regularly, but it is still really nice if you ask me.

I use CSS variables to enable the Color Picker onJackHarner.com.

I define the defaults as

:root {  --color: #E91E63;  --text-color: white;  --darkerColor: #AA1145;  --darker-text-color: white}

Then take the color chosen from the Color Picker, calculate the slightly darker value, calculate what color text is good on both of those colors and adjust the CSS vars accordingly.

That way all the content still shows up with appropriate contrast and users are free to select whatever color they want.

I tend to name colors to experiment when developing a theme. These can then be assigned toprimary-color etc.

:root{  --budapest: #bd7898;  --oprah: #a060a8;  --sakura: #e6781e;  --unsugar: #349e97;  --keep-going: #ec2865;  --fogg: #999999; /*good colorlovers */  --laphams-gold: #cdac77;  --green:#34AB01; /* select the colors here */ --primary-color: var(--keep-going);  --selection-color: var(--unsugar); }/* *  Set the default links *  at this point we do not need underlining?*/a {  color: var(--primary-color);  ...}

I mostly use preprocessors but this seems like a natural evolution for css. And like all modern css features, IE support makes it obnoxious. If I'm adding fallbacks, and still want consistency on IE, I'm back to find and replace.. and at that point, why even bother with the css vars.

Seems like a great way to start of the 2020 goals early! I always like it when I find that I can use CSS built-ins to accomplish the task at hand.