Coming Soon: Native CSS Variables

By Craig Buckler

Name one feature you’d love to see in CSS. Hands up those who want variables… (I’m sure some of you are desperate for parent selectors but you’re in the minority!)

The issue stems from our need to use and repeatedly re-use the same colors and other values throughout a stylesheet. For example:


section { border-color: #334; }
h1      { color: #334; }
p       { background-color: #334; }

Maintenance is tougher than it need be. We need to remember a range of hex/RGB values and, inevitably, the finicky client or designer will decide #335 is “on-brand”. Search and replace might work, but not if you’ve used #333344 in some places or rgb(21,21,2c) in others.

CSS variables solve the problem. You define #334 as a single named variable and use it throughout your code. It’s usually the first feature implemented in CSS pre-compilers. For example, in LESS:


@mycolor: #334;
section { border-color: @mycolor; }
h1      { color: @mycolor; }
p       { background-color: @mycolor; }

or Sass


$mycolor: #334;
section { border-color: $mycolor; }
h1      { color: $mycolor; }
p       { background-color: $mycolor; }

Fortunately, native CSS variables will arrive soon. There’s a draft W3C specification at http://www.w3.org/TR/css-variables/ which reveals how we may be writing CSS code when vendors begin to implement support.

According to the document, any property name starting with the ‘var-‘ prefix is a variable property. For example:


:root
{
  var-mycolor: #334;
}
section { border-color: var(mycolor); }
h1      { color: var(mycolor); }
p       { background-color: var(mycolor); }

Perhaps that’s not as concise as LESS/Sass, but it’s a big step forward which will ease the maintenance issues we’ve all encountered.

It’s an exciting development but don’t hold your breath. There’s no guarantee it will be adopted by all vendors and, even if they do, the feature does not appear to be backward-compatible with older browsers. Our great grand-children will love it, though.

CSS, CSS3, HTML5 Dev Center, variables

Meet the author

Craig Buckler

Craig is a freelance UK web consultant who built his first page for IE2.0 in 1995. Since that time he's been advocating standards, accessibility, and best-practice HTML5 techniques. He's written more than 1,000 articles for SitePoint and you can find him @craigbuckler

Diego Andrade

This is a great solution and a great problem at the same time. I’d like to see the standardization of the implementations of LESS or SASS rather then this specification. Since we already use those patterns it would be a natural choice to make them (or some of them) standard.
Trevor Geene

I am really looking forward to this addition to css. Makes things much easier for designing.
Sid

I think this is a great news. Once variables are introduced, the developers will find creative ways of using them!
Satya Prakash

LESS style looks easily distinguishable. Why don’t they use that and do good job at first go.
- Craig Buckler
  
  I suspect the W3C proposal is easier for vendors to implement in existing CSS parsers. The LESS and Sass syntaxes are a little too different to CSS rules.
Brian

A step forward. And +1 for parent selectors, would love to see that!
- Craig Buckler
  
  I have to admit I’d probably find parent selectors more useful!
Richard Razo

I’m late to the rodeo. I still have yet to use Less or Sass but I plan to. Anyways, doesn’t Less or Sass require JS so wouldn’t it be better to eventually have it built into CSS so we aren’t making another request to the server and slowing down our web pages speed? As the author pointed out it will be a long time for this native CSS to be supported in all major browsers so I still plan to learn and utilize eith er Sass or Less.
- Anonymous
  
  Utilities that compile less and sass to plain jane CSS are available. So no they do not require JavaScript.
- Craig Buckler
  
  LESS and Sass are CSS pre-compilers. In essence, they translate their own syntax into browser-compatible CSS. That can either happen on your development machine or on the server.
  
  The advantages: they can save development and maintenance time. The disadvantages: pre-compiling is an extra step and the resulting CSS may bear no relation to your input file — errors could be more difficult to debug.
- Patrick
  
  Use Stylus. Better than Less and Sass, but oddly doesn’t seem to get much mention. It has a more flexible syntax, better error reporting, and far more features than Less does (it’s roughly feature-equivalent to Sass). I switched from Less about 4 months ago and never looked back.
  
  JS is not necessary at all – I’d always recommend compiling to CSS on your own computer when using any CSS preprocessor language.
Keithics

I have been developing websites for almost a decade and this will surely help to future developers! Hopefully vendors can apply this quick!
Patrick

I find it very hard to be excited about this. It’s about 10 years too late. It’ll take years for browser support to be sufficient for it to be useable in real projects. Maybe in 2018 it’ll be useful. And the syntax is horrible and clunky. Even if this feature was widely supported today, I’d still use Stylus (or Less or Sass), because it offers a nicer syntax, error reporting, and about a dozen additional features.

CSS preprocessors have already given us this feature, and it’s available and works today in all browsers, with a nicer syntax and all kinds of other goodies. So instead of arriving late to the party with an ugly implementation of a feature that more innovative people have already provided, maybe the W3C should focus on getting stuff like the grid/layout module working. Wouldn’t it be nice if we could have equal height columns without using some ugly hack? Or if we could position elements precisely on the screen without worrying about clearfixes and margin collapsing and a dozen other problems we face trying to get simple layouts working? That’s something that CSS preprocessors can’t give us, and it’d be infinitely more useful than this awkward attempt at a feature we already have.
Liam

I find it strange that they wouldn’t build upon the ground work set out by the current pre compilers.
- Craig Buckler
  
  I’m not convinced that would be particularly easy. Pre-compilers have their own syntaxes which can be totally different to the final code. It’s taken long enough for browsers to adhere to CSS — let’s not introduce further options!
- Patrick
  
  Agreed. I find it strange that it takes the W3C years to do something relatively simple, when there’s already several examples of how to do it (in the form of the different preprocessors). It’s not like they even had to think particularly hard about scoping issues or anything, since preprocessors already dealt with those problems and found a good way to handle them. Syntax aside, the way variables should work is already established, so I don’t understand why it takes years (literally – they’ve been working on this since 2008) to draft a spec for it. I could have written this draft in a weekend.
Chris Emerson

Finally! This took far too long. Next should be regex selectors (with backreferences available to be used in the properties) & parent selectors. Maybe we’ll see these by 2030…
AnilG

What an appalling kludgy over-verbose syntax. I hope it never gets adopted.
Stevie D

Will you be able to use variables more widely? What I think would make them even more flexible and valuable would be to use them /within/ an HSL declaration. So, for example, you could declare a property to be hsl(var(theme),50%,85%), so that var(theme) is used consistently throughout and you can adjust the shading as appropriate – or vice versa.
Subash

Css variables will be great addition.
May be we could use that in 2020 but the latest ie10 will be a new ie6 bummer for us.
Colin Pittendrigh

Variables would be even more useful than parent selectors–I agree. But I want both. What’s the big deal about parent selectors? Is it hard to implement? It should have been a ground zero no-brainer. You get the parent with XML and XPath. Why not in CSS? It would be useful. (if mouse over this, then adjust the parent).
- Craig Buckler
  
  I’m not saying it’s an either/or situation and it’d be great to have both.
  
  As I understand it, parent selectors are quite tricky to implement because of the way CSS parsers work. It is coming, but not for a little while yet.
  
  XPath does allow parent selection, but remember it works in a fairly programmatic way and rendering speed is not necessarily as important.
Jason

People do realise that there is a find/replace feature for quick maintenance of CSS documents? Variables do NOT make code easier to read.
- Craig Buckler
  
  Really?
  So you find it easier to read “#14078b” or “rgb(20,7,139)” than “var(darkBlue)”?
  Each to their own.
  - Jason
    
    I’ve been reading “#ff0000” for the past 12 years, so yeah. I find it easy to scan for those patterns.
    
    rgb should never be used… ever.
    
    what is var(darkBlue)? is it the dark blue on the footer or the nav? are they the same. who wrote this code… what does var(otherBlue23) mean?
    
    People can’t write clear class names Craig, what chance do you think they will have with variables lol… wrong tool for the WRONG people.