Firefox 31 was released on July 22, 2014. You probably already have it but, if not, open the About Firefox dialog from the menu or head to Firefox.com to download a fresh copy.

Don’t expect too many surprises. There are a few new locales and developer tool tweaks but only one major addition: CSS variables. Firefox 31 is the first mainstream browser to support native CSS variables without having to enable experimental features.

CSS Variable Syntax

I first wrote about CSS variables in September 2012. We’ve waited a considerable time and you should note that the syntax has changed.

To declare a CSS variable:

element {
  --my-variable: #c00;
}

where:

  • element is a selector. The variable value is available to all styles that inherit from this selector. Use :root if you want the variable to be available globally throughout your page’s stylesheets.
  • ‐‐my-variable is the variable name. It must start with two hyphens followed by a name of your choice. Naming conventions seem quite loose and you can use most characters except for those required by CSS syntax, i.e. : ; { }. That said, I’d recommend keeping them simple and sticking to alpha-numeric characters.
  • Finally, you set the value after the colon. Any type can be defined and used elsewhere, e.g. colors, fonts, dimensions, transition settings etc.

Example:

:root {
  --my-font: arial, helvetica, sans-serif;
  --my-color: #333;
  --my-background: #fff;
  --page-width: 80%;
  --max-page-width: 50em;
}

The variables can now be referenced when necessary using the var functional notation, e.g.

body {
  font-family: var(--my-font);
  color: var(--my-color);
  background-color: var(--my-background);
}

main {
  width: var(--page-width);
  max-width: var(--max-page-width);
}

Browser Support

CSS variables have a W3C Working Draft Specification but support is limited to Firefox 31 and above. The other vendors have not committed either way so, for the moment, you should probably avoid using native CSS variables unless you’re catering for a Firefox-only audience.

Too Little Too Late?

Native CSS variables would have revolutionized our working lives had they been implemented a decade ago. Today, if you want to use variables in your stylesheets, you probably already are. Preprocessors such as Sass, Less, and Stylus provide variable functionality with many other benefits:

  1. There are no browser support issues.
  2. Variable syntax is simpler, e.g. $my-variable in Sass/SCSS.
  3. Variables are pre-processed once rather than every time the page is rendered.
  4. Incorrect syntax is reported by the preprocessor.
  5. You can take advantage of programming language-like features such as includes, nesting, mixins, functions, conditions, loops and more.

Admittedly, you’ll need to spend a little time installing a preprocessor and learning some syntax options but you’ll be productive within a few hours.

Once we have better browser support, perhaps native CSS variables will be practical for smaller projects, mock-ups, tutorials and demonstrations. Until that day, I suspect they’ll be of little use for most of us.

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

Free Guide:

How to Choose the Right Charting Library for Your Application

How do you make sure that the charting library you choose has everything you need? Sign up to receive this detailed guide from FusionCharts, which explores all the factors you need to consider before making the decision.


  • deconai

    So, why the odd syntax? There was so much legwork done for variables in CSS preprocs, I’m sure it’s a super-complicated issue to be sure.

    • Craig Buckler

      Yeah, it is a little odd. Why is the double hyphen required if you need a `var()` to use that value?

  • Aurelio De Rosa

    I absolutely agree with your analysis. Today having variables is a too small advantage to still use pure CSS only and avoid preprocessors. In addition, the syntax is awful.

    • Matt Wistrand

      Agreed. I’m sure there were reasons for adopting a completely new syntax, but it would have been nice if they were able to “pave the cowpaths” by choosing one from the existing, widely-used preprocessors.

  • Google

    The syntax is ugly.

  • Aghts

    The double dash (–) is a nonsense. Much better would be a dollar sign ($) as in PHP.

    In case you didn’t know, you can make expressions too:
    –bar: calc(var(–foo) + 10px);

  • zymara

    Agree, too little, too late, already jumped on the Sass bandwagon and won’t be looking back.

  • Oscar Blank

    If you’re using Grunt, you can setup Sass along with all of your other tasks, and the benefits are so great that using these CSS variables seems like stone-age coding. So then what, we use Sass variables to make CSS variables, LOL!

  • George Bora

    I disagree with your conclusion (that it’s too little too late) there’s a huge number of shops which don’t use pre-processors for a variety of reasons, from their perspective this is a huge thing and I’m sure they’re eagerly awaiting for the other major browsers to implement this as well.

    Even from the perspective of a user of pre-processors (mostly Less in my case but also some Sass) this will help us, as to learn the pre-processors you need to start from CSS and in the future those making the switch will allready have the habit of working with variables.

  • Ralph Mason

    Dearly wish they’d chosen $ instead of — … but other than that, I hope this does get implemented, as it would be a great too to have (especially for those of us who shun preprocessors).

  • Vote 539

    I feel like this is a very strange syntax for the W3C to adopt, and it’s not one that feels very intuitive for me. In 2012 the spec had variables defined using the var-NAME prefix, which seems more natural. My favorite syntax from the mailing list is the $(NAME) syntax.

    Variable definition is an incredibly important syntactic change to CSS. I would love to read a digest of the W3C mailing list discussion on the topic. Here is the root of the thread where the W3C decided at the last minute to change var-NAME to --NAME; I had time to read through some of it, but there are something like 100 replies.

  • http://hugogiraudel.com/ Hugo Giraudel

    Regarding your last section about preprocessors variables versus native variables, I feel like you are totally missing the point of native variables.

    Among other things:
    – They are nothing but custom properties…
    – … which cascade, that’s why they can be set in :root for the whole stylesheet…
    – … and thus are accessible through JavaScript (with an upcoming API).

    Needless to say a preprocessor, by virtue of its nature, can do that.

    • Craig Buckler

      I’m sure native variables will have some good uses and I’m guessing the API will permit dynamic changing which could be interesting. That said, they’ll still be mostly used as simple replacement and calculation values — like you can do in pre-processors now.

  • Craig Buckler

    Even if you don’t need or want to use a pre-processor, an editor with search and replace will be more useful until the majority of browsers support variables. None of the other vendors appear too keen, though?

Learn JavaScript for free!
Free course: Introduction to JavaScript

Yours when you take up a free 14-day SitePoint Premium trial.