(Auto) Prefix All The Things

When I first had a look at Sass mixins, I immediately thought, “Wow, I’ll never have to write vendor prefixes by hand ever again!”

That excitement, I’m sorry to say, was misplaced. Prefixes are much maligned, but the worst thing they did was distract us from solving real problems. Early on, our focus went into building libraries of mixins designed to handle prefixes. Instead we could have been focusing the incredible power Sass gives us to address tougher problems. What a shame.

There is a solution we have adopted called Post-processing. A post-processor is a build tool that parses plain CSS and performs some task on that code. It then spits out a new CSS file with the changes made. It’s compatible with pre-processors like Sass because it runs after the CSS is compiled from Sass.

Autoprefixer

Autoprefixer is perhaps the best known and most widely adopted Post-processing tool. It’s the perfect place to get your feet wet. It is mature software, it solves a major problem with minimal configuration, and it’s flexible enough to fit into almost any build process. If you are building a website, there is a place for Autoprefixer.

Installing and Using Autoprefixer

At Happy Cog, we rely on Grunt to do our heavy lifting, but every shop is going to be different. There are versions of Autoprefixer available for Grunt, Gulp, CodeKit, and more.You can even install Grunt as a text editor plugin for Sublime Text or Atom in a squeeze. Ideally though, you will want to use Autoprefixer as part of a build process so you’re not converting properties by hand.

If you use Grunt as well, grab the grunt-autoprefixer task and get it installed. If you don’t already use Grunt or a similar build tool, I recommend Chris Coyier’s excellent article on getting started. Once installed the configuration looks something like this:

 
 grunt.initConfig({
 autoprefixer: { `
 options: {
 browsers: [
 'last 2 versions',
 'Explorer >= 9',
 'Android >= 3'
 ]
 },
 dist: {
 src: 'path/to/css/main.css'
 }
 }
 });
 

The `options.browser` option provides prefixes for the latest two browser versions. IE and Android are special cases, since their turn over to new browser versions generally lags behind. So for IE, I included IE 9 and above and for Android, version 3 and above.

Then just include `autoprefixer` in your build task.

 
 grunt.registerTask('default', [
 'html',
 'js',
 'sass',
 'autoprefixer',
 'watch'
 ]);
 

To be clear, we always want to set Autoprefixer to run after Sass. It’s called a post-processor, after all.

Just write CSS

Now that everything is set up, go out and write your Sass or CSS with un-prefixed properties in line with the spec. With Autoprefixer you are free from the shackles of vendor prefixes. Use all your flexboxes, transforms and animations completely without prefixes. In other words, you can write this illegible, monstrous block of CSS:

 
 -webkit-transform: translate(-50%, -50%);
 -ms-transform: translate(-50%, -50%);
 transform: translate(-50%, -50%);
 -webkit-transition: all .25s ease-in;
 transition: all .25s ease-in;
 -webkit-hyphens: auto;
 -moz-hyphens: auto;
 -ms-hyphens: auto;
 hyphens: auto;
 -webkit-animation: fadein 1s ease 1 normal;
 animation: fadein 1s ease 1 normal;
 

Into a far more readable, maintainable and concise few lines of CSS:

 
 transform: translate(-50%, -50%);
 transition: all .25s ease-in;
 hyphens: auto;
 animation: fadein 1s ease;
 

I can’t stress how big a difference this has made in my day-to-day. To focus on real CSS, from the spec, is a dream-come-true.

Targeted Browser Support

As I alluded to earlier, Autoprefixer determines what prefixes to use automatically. It draws from data on Can I Use to determine what prefixes are necessary for what browsers. If you don’t set any browser options, it will support the last two major releases of each browser by default. As shown above, this is customizable into any permutation of support your project requires.

There are some limitations: testing is still necessary. Sometimes hacking CSS is necessary particularly for the old browsers, though Autoprefixer does include a number of established browser hacks to make life easier. Poly-filling browser support is not supported—we don’t recommend it in most cases anyway for performance reasons. Include a build of Modernizr and write CSS to match your target browsers strengths.

Quicker Compile Time

If you have been using Compass or Bourbon to manage prefixes, you likely see a performance drag with compile times. The great thing with Post-processing is that there is no need to drop your pre-processing workflow. Since Post-processing works on a flat CSS file, you can run it after your Sass compiles. In some cases, it may not be out of line to entirely drop dependencies like Compass or Bourbon.

Consider using those freed resources to focus on more useful Sass tools. Include a library to create grids or a library of practical tools.

This is Just the Beginning

In truth, Autoprefixer has been around for awhile. As an established example of the usefulness of Post-processing, it’s a stand out. Once you’ve dipped your toes in, there are many more Post-processing tools you can experiment with. Retire that rem mixin and use Pixrem to get your pixel fallbacks for free. Lint your stylesheets written in the BEM methodology for future maintainability with BEM linter. Set Sass to compile extended stylesheets and compress in post with CSSWring.

Post-processing is ‘set it and forget it’. Install the task in your build process, set your desired configuration, and then let it do the job you don’t want to waste time doing. Take that time and effort saved and zero in on what matters. Get started with Autoprefixer and soon you’ll be saying, like I do, “We’ll do that in post.”

Back to Top