Alternatives to Prefixr

Awhile ago, the awesome Jeffrey Way created a tool called Prefixr which was meant to help with the onerous task of managing vendor prefixes in your stylesheets. It worked by analyzing your stylesheet and automatically adding the vendor prefixed version of different rules into an output that you could then paste into your file. It was a pretty slick tool.

Unfortunately, now that the site has gone the way of the dodo bird and after having several users ping us about it, we wanted to provide some alternatives that can help provide similar capabilities.

The Express Prefixr Library

The first option which is closest to the functionality of Prefixr is a site called Express Prefixr. This was created by the awesome TJ Holowaychuk who apart from being an expert on Node.js development, also created the Express web application framework for Node.js.

With Express Prefixr, you're presented with two textarea fields, one for entering your styles and the second to receive the prefixed output from the service. This is very similar to the way that Prefixr worked:

To test this out, I'm taking the same code sample that Jeffrey used in his original article:

One final great thing about Express Prefixr, is that the code is available on GitHub allowing you to easily fork it and customize the software to your needs.

The Autoprefixer Library

The next option is actually designed to integrate more so into your workflow, rather than being a visual UI tool. Autoprefixer does in fact add prefixes where appropriate by using rules provided by the popular site, Can I Use. Autoprefixer's slogan is:

Take a close look at the syntax. Notice that the transition rule was pretty much left alone except for the addition of the two Webkit-specific entries. That's because Autoprefixer only applies vendor prefixes when it's appropriate. In this case, transition is widely supported in modern browsers and doesn't really need to be prefixed.

But, the :fullscreen pseudo-class is still evolving and does need to be properly prefixed. Autoprefixer, using the Can I Use data, is smart enough to determine when to prefix something based on a browser's level of support for a feature. Very cool!

The thing to note is that Autoprefixer is meant to be incorporated into your normal deployment workflow. It's not a client-side library and you leverage it via any number of third party integrations. This includes:

And so many more options. Even the new Atom Editor now has the atom-autoprefixer package which shows that Autoprefixer is well-maintained.

If you'd like to see Autoprefixer in action, jump on over to the following demo and add a bunch of CSS rules that you've traditionally had to vendor prefix and see how it works for you.

The -Prefix-Free Library

The final option is a great client-side library by Lea Verou called -prefix-free. Lea's been a long-time advocate of cross-browser development and built this library to, as a bit of a shim, ensure that your site uses all of the proper vendor prefixes. She built it at a time where, unfortunately, many web developers were simply forgetting to add all of the appropriate prefixes, causing sites to not render properly across all modern browsers.

The key difference between this and the two others I mentioned previously is that -prefix-free is a JavaScript library that looks at your stylesheets in runtime and adds the vendor prefixes when needed.

Using the library is as simple as adding the following line to the head of your page:

<script src="prefixfree.js"></script>

No, seriously. That's it. The library handles the processing of every stylesheet in link or style elements and adds a vendor prefix where needed. This is especially useful for sites that are already deployed and it may not be possible to go back and update it.

It also has solid browser support being compatible with IE9+, Opera 10+, Firefox 3.5+, Safari 4+ and Chrome on desktop and Mobile Safari, Android browser, Chrome and Opera Mobile on mobile.

Hoping Vendor Prefixes Go Away

It's great to have alternatives to Prefixr and these solutions certainly fit the bill. Ultimately, though, vendor prefixes have become more complicated than they're worth and with many developers not respecting the original intent of them (for example, to designate experimental features) and leveraging them in production systems, hopefully they'll go away in the near future.

Thankfully, Google mentioned when they announced their Blink rendering engine, that they would be shifting to a feature-flag model which would hide experimental features behind hard-to-set flags which aren't accessible via code. Thank goodness!