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 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;


  • 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.


: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 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
  • 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.

  • 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!

  • 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).

  • 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?

Stay ahead of the game Exclusive content for developers and digital experts Go Premium