How To Handle CSS Prefixes

CSS preprocessors are a great way to code quickly and efficiently. There are many ways to utilize these tools, in this article we discuss the popular options.

CSS History

Remember back in the day when you had to write CSS like this?

div {
float: left;
margin: 0 6px;
display*: inline-block;

The issue came from browsers not rendering consistently. The asterisk above was a hack that would fix a double-float margin bug in IE6. Thankfully, we’ve gotten away from that and browsers today are able to render our CSS across the board consistently—sort of.

Today, we’ve replaced browser-specific hacks with vendor-specific prefixes. We all thought browser hacks were a thing of the past with the release of CSS3, and we could simply write our CSS without pesky * html {} or _color: rules and properties, and we can. But instead of hacks, we replaced them with fancy “experimental” properties that everyone knows about, but browsers haven’t decided on execution yet.

Something like this:

div {
background-image: linear-gradient(to bottom, white, black);

Turns into this:

div {
background: #ccc;
background: -moz-linear-gradient(top, white 0%, black 100%);
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, white), color-stop(100%, black));
background: -webkit-linear-gradient(top, white 0%, black 100%);
background: -o-linear-gradient(top, white 0%, black 100%);
background: -ms-linear-gradient(top, white 0%, black 100%);
background: linear-gradient(to bottom, white 0%, black 100%);
+        filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#ffffff', endColorstr='#000000',GradientType=0 ); }

Not exactly easier than browser hacks. Basically, browser vendors begin experimenting with new CSS features before there is an official ruling on how those features should be implemented. What this means is that each browser tries to create a new feature and comes up with their own syntax on how they think it should be implemented, and we get stuck with writing umpteen lines of code to cover all those syntactical differences. Not the ideal situation, and not exactly dry.

There are helpers out there, though; some tools that have been developed specifically to fix this kind of mess. A few key capable people got sick of spending their days writing countless lines of repeat code and decided to develop a better solution. A couple really great ones are Autoprefixer and the Lesshat Mixin Library. Here is a brief discussion on how to use them, their benefits, and some ‘gotchas’ about each one.

Lesshat Mixin Library

If you’re using a CSS preprocessor (and you should be), and that preprocessor is Less, then the Lesshat Mixin Library might be something to look at. It provides mixins that allow you to write a single line, and it takes care of the rest. It looks something like this:

@import "lesshat";
div {
.background-image(linear-gradient(to bottom, white, black));

The great thing about the Lesshat Mixin Library is that it stays as close to the real-life CSS properties defined by the W3C as possible. So you’re not dealing with trying to remember what the mixin equivalent is for the various properties out there that need prefixes. There are several libraries out there that handle gradients like this:

div {

With these, you have to remember that a linear gradient is one mixin, radial is another, and whether shadow is for boxes or type. There’s a pretty good chance that these accept arguments that look nothing like the actual property values defined by the W3C, so expect to be remembering the order of the arguments as well.


This one’s really easy. You simply download the Lesshat file, import it into your Less stylesheet, and away you go. You can see its list of mixins on its Github page.


@import 'lesshat';
div {


Lesshat can conflict with other mixin libraries that you might have imported into your project. A good example is Bootstrap, which has its own set of mixins. To deal with this, download the prefixed version of Lesshat instead, and call your mixins as follows:

@import "lesshat-prefixed";
div {


Autoprefixer is a post-compiler, meaning it runs on your CSS files every time your CSS file is saved. If you’re using a preprocessor (and again, you should be), then this means it will run through your CSS each time it’s generated.


Autoprefixer is run through some command line entries. To install directly from the terminal, install the node package manager, and then install Autoprefixer:

# install npm
curl -L | sh

# install Autoprefixer
sudo npm install -g autoprefixer

Use: To have Autoprefixer watch your CSS file for changes, and add the prefixes when it does, enter in this command:

autoprefixer path/to/file.css

If you’re using Codekit 2 like we do here at Zion & Zion, you can simply add your project to Codekit; go to “Special Language Tools”, and check the box.

There are also a couple options for Autoprefixer, where you can define how far back you want Autoprefixer to support browsers. For us, we like to stay within the most recent two versions of the major browsers, and IE9+. To configure Autoprefixer, we would use this command:

# configure browser support
autoprefixer -b "last 2 versions, ie >= 9"


Autoprefixer takes a bit longer to set up, and doesn’t handle some of the cooler stuff like Lesshat does. Lesshat provides a couple polyfill snippets inside their mixins such as generating SVG fallback images for gradients; Autoprefixer does not. However, if all you want are prefixes to be generated, and you’re providing your polyfills elsewhere, then this tool is perfect for the job. Nothing is better than getting back to your roots and writing the following:

div {
background-image: linear-gradient(to bottom, white, black);


Basically, stop writing prefixes. There are way too many options out there that will handle the job for you. I prefer Autoprefixer, a couple other developers here at Zion & Zion prefer Lesshat, and there is of course the myriad of other agencies using other tools to get the job done. Gone are the days of writing messy, redundant CSS and wasting precious time.