Write CSS3 without Worrying about Prefixes

By James Steinbach

Using CSS3 properties can give your websites a huge boost in appeal and interactivity. 3D transformations, keyframe animations, background gradients, and columns are great tools, but they require extra work on the developer’s part. Various browsers support them experimentally and require vendor-specific prefixes for these properties. Here’s an example of what I mean:

.rotated-element {
  -webkit-transform: rotate(45deg);
      -ms-transform: rotate(45deg);
          transform: rotate(45deg);

In order to use this transform property across modern browsers (that is, anything after IE8), two additional copies of the rule are needed: -webkit- (for Safari, Mobile Safari, and recent Chrome) and -ms- (for IE9). Firefox (16+) and Chrome (36+) read the unprefixed property correctly.

A site that uses lots of CSS3 properties therefore needs lots of prefixes. That raises two problems. First, how do you know which prefixes to use? Sometimes you’ll see a site that uses everything (-webkit-, -o-, -moz-, -ms-, and unprefixed). That’s just bloat. You could look up every property on Can I Use, but that’s time-consuming. The second problem is simply that nobody wants to write all those prefixes.

We need to automate this. Let’s look at some tools that help us automate vendor prefixes.

Preprocessor Mixins

If you’re using a preprocessor to write your CSS, you can use a mixin library to manage your prefixes for you. For Sass, the major libraries are Bourbon and Compass. For Less, there’s LESS Hat and LESS Elements. Stylus appears to have its own set of mixins built-in.

While these mixin libraries are much better than prefixing everything by hand, there’s a concern you should be aware of: they may give you more prefixes than you need. Browsers are updating constantly (Firefox and Chrome seem to release new versions almost weekly!), and those updates can include full support for various unprefixed CSS3 properties. How does your mixin library track newly added support and decide when to stop outputting unnecessary prefixes?

Some libraries don’t pay much attention and you’ll end up with unnecessary prefixes years after they’re no longer necessary. If your library is still putting prefixes on border-radius or box-shadow, it’s guilty on this count.

Some libraries just push an update every few months and drop prefixes based on decisions their dev team makes.

The best kind of mixin library allows you to configure what browsers you need to support and outputs prefixes to match your specs. Compass is this kind of library. It relies on data from Can I Use and allows you to set minimum browser support with some global variables. Check out their documentation for this configuration. Using the $supported-browsers variable, you can define a list of supported browsers. The $critical-usage-threshold variable allows you to set a minimum global usage percentage for browser support (for example, if a browser comprises at least 1% of global usage, add any prefixes it needs).

Problems with Mixin Libraries

I don’t personally use a mixin library because of a couple of additional concerns I have. First, libraries still make you write more code than you need to. Instead of transform: translateX(25%); you’d need to write @include transform(translateX(25%));. That’s an extra word and a few extra symbols. Not huge, but over the course of a day, it does slow you down.

I also don’t like the fact that I have to learn a library’s syntax instead of real CSS syntax. I had been using a library for several months when it hit me that I couldn’t write the spec version of certain CSS3 properties off the top of my head. I’d rather know real CSS than a preprocessor’s mixin library.


These tools include -prefix-free and Autoprefixer. With these, you write the standard spec version of all CSS3 properties, and the tool adds the prefixes for you later. Neither of these tools requires a preprocessor, but both fit in fine with a preprocessor workflow.

-prefix-free is a JavaScript tool developed by Lea Verou. You include it in the page like any other JS file (only 2KB when gzipped, so not the heaviest file at all!) and it runs client-side. -prefix-free detects the user’s browser, finds CSS in <link>, <style>, and inline, and adds exactly the prefixes that the browser needs. This saves you time and keeps your stylesheets lighter. The drawback to this method is that it runs client-side, so your users may see a rendering delay or FOUC on heavy pages. Including -prefix-free immediately after your stylesheets helps minimize that delay.

The tool I use is Autoprefixer. Autoprefixer runs on your local machine and corrects your prefixes before your stylesheet ever hits a browser. You can install it as a Ruby gem, run it in a Grunt workflow, or a Gulp workflow. I typically compile Sass with compass watch in Terminal, so I add the following require block to my config.rb file to tell Compass’s compiler to run Autoprefixer (Ruby gem) as soon as the Sass is compiled:

require 'autoprefixer-rails'

on_stylesheet_saved do |file|
  css =, 'w') do |io|
    io << AutoprefixerRails.process(css, browsers: ["last 3 versions"])

If you’re using Grunt or Gulp, I’ll assume you’re familiar with adding a new task and move on to details about Autoprefixer.

Autoprefixer runs on a browsers config list: in it you can specify recent version numbers ("last 3 versions"), specific browser versions ("Firefox > 20"), or global usage ("> 4%"). Global usage stats are based on live data from Can I Use. The default value is "> 1%, last 2 versions, Firefox ESR, Opera 12.1". Unlike -prefix-free, Autoprefixer adds every prefix that fits your config requirements. This does cause a slightly heavier stylesheet, but that’s probably worth it for the speed you gain from not having to run a script client-side.

Autoprefixer also cleans up unnecessary prefixes. If you’ve inherited a project from a developer who had some sort of prefix-mania, Autoprefixer will remove whatever prefixes aren’t necessary for your browsers config requirements, making your stylesheet lighter automatically!

If you’d like a great introduction to Autoprefixer, check out this article on CSS-Tricks, written by the creator of the tool.


CSS3 properties are awesome and you do not need to waste time writing prefixes for them. Whether a mixin library or a postprocessing tool fits your workflow better, you can automate this part of your coding and get more done!

  • Dan Walker

    [this article on CSS-Tricks] link missing.

  • Jaz

    It might be worth mentioning that prefix-free still breaks on @import

  • artuska

    Yet another article about Autoprefixer. Well, I really wonder somebody does not know about Autoprefixer in 2014 in 21-st century.

    • LouisLazaris

      True, maybe… But reasons beginners. The web development world doesn’t revolve around those of us who have been in the loop the last 5 years. :)

      • James Edwards

        Or indeed, those of use who’ve been in the loop for the last 15 years :-) I’d never heard of Autoprefixer, and I’m not going to start using it, but it’s still interesting to read about.

        Personally though, I don’t buy the central premise — that tools like this save you time. The time involved in physically typing is just a small proportion of coding time. The biggest proportion is thinking, and you can’t automate that.

    • M S i N Lund

      Good point.

      I have contacted the article writers of the Internets, and we have decided that from now on only articles about things you know nothing about, will be publicized.

      Thanks for helping make the world a better place.

  • MoOx (Maxime Thirouin)

    If you want to go forward, take a look to cssnext directly ;)

  • shobi

    Guys here is new css3code generator website.



Because We Like You
Free Ebooks!

Grab SitePoint's top 10 web dev and design ebooks, completely free!

Get the latest in Front-end, once a week, for free.