The rocky introductory days of CSS3 were where I cut my teeth as a web developer, and it was where I learnt how much I disliked prefixes.

I remember distinctly reading about how, if I wanted to use the border-radius property, I needed to add vendor prefixes such that my code looked like:

.my-class {
  --webkit-border-radius: 3px;
  --moz-border-radius: 3px;
	border-radius: 3px;
}

Eventually, I found some editor tools that made it easier to macro out these prefixes, before stumbling upon mixin tools for preprocessors like Compass that made it easy to write.

But it never felt quite right to me (you needed to remember another syntax), and quite honestly with the pace of browser upgrades these days, it’s hard to remember what needs to be prefixed. That’s not to mention the need to build your own fallbacks for flexbox if you need to support IE10 or below (macros aren’t going to cut the mustard for flex).

Then, one day I found Autoprefixer, and I fell in love. I’m going to share why I love it.

The simple magic of autoprefixer

Autoprefixer is a plugin for PostCSS, which takes in a CSS stream, and transforms it with a bunch of plugins. Think of PostCSS as Babel but for CSS - it parses the language on a deep level and can even handle additional language rules you might have written.

Both of them work with most existing build pipelines - so if you make use of LESS, Sass, or Stylus, Webpack, Grunt or Gulp, you’ll be able to fairly easily use PostCSS and any plugins (including Autoprefixer) by including it as a pipe. Usage docs on getting started can be found here.

Once you’ve included it in your build process, all you need to do is start writing plain, vanilla CSS without any prefixes…and that’s it. You’re done. All CSS output by PostCSS will now include the prefixes as specified by the default browserslist configuration (at time of writing: all browsers with > 0.5% web traffic according to caniuse.com, last two versions of all browsers, Firefox ESR, and any browser that is “not dead” [any browser that has received updates in the past 24 months]).

It handles pretty much every CSS feature released in the past few years (with the exception of CSS Grid which is a bit more complicated). And that’s super cool. You can write flexbox/animation/whatever CSS and it’ll just work for everyone.

If you love checking out the gory bits and implementation details and want to understand PostCSS on a deeper level, I’d recommend you taking a read of this article on PostCSS: It’s Time For Everyone To Learn About PostCSS.

It supports browserslist as a configuration source ✅

Your product team probably has a set of browsers it supports. Most people probably knows the list of browsers. They probably know the ones they hate supporting. But they don’t always know what isn’t supported by what.

Autoprefixer allows you to use browserslist, which is a domain specific for specifying browsers you want to include support for. It’s also supported by Babel as a way to determine what browsers you actually want to polyfill for.

It cleans up old prefixes for you for free 🥳

This one was the coolest by far. If you, like us, have old mixins (think Compass, LESShat, or maybe one you’ve rolled yourself) that do a bunch of prefixing, you might be worried about it clashing with Autoprefixer.

Because it uses PostCSS and can be a bit smart about what gets pushed out, Autoprefixer actually sucks up unnecessary rules that don’t match your browserlist support.

So if you had:

.my-class {
  --webkit-border-radius: 3px;
  --moz-border-radius: 3px;
	...
	border-radius: 3px;
}

But you only support the latest browsers (or even latest evergreen browsers), when you run Autoprefixer, it’ll automatically output:

.my-class {
	border-radius: 3px;
}

This is kinda amazing to me (and helped us actually drop ~100kb from our unminified, un-gzipped bundle).

You can even run it in the browser 🤯

If you, like us at Qwilr, occasionally need to generate CSS on the front end (i.e. not as part of a build step but dynamically), you too can do that! PostCSS, and by extension, Autoprefixer, work in the browser as long as you use a bundler like Webpack.

You can use it with something like this:

import postcss = require("postcss");
import * as autoprefixer from "autoprefixer";

const prefixRawCss = async (rawCss: string) => {
	const processedCss = await PostCSS([autoprefixer]).process(css)
	return processedCss.css;
}


// Example usage
(async () => {
	const output = await prefixRawCss("");
})()

I think that’s pretty cool.

PostCSS is the start of a magical CSS build pipeline for your team 🌈

PostCSS does so much more than just power Autoprefixer - you can use it to build shiny grid systems that work like CSS rules, lint your CSS to make sure all features can be supported by your targeted browser set, or write your own custom rules and properties.

Finishing up

So, to recap:

  • It’s pretty easy to get started with if you already have a build pipeline
  • It supports using browserslists to prefix so if you already have one of those, even less config required to get it working
  • It cleans up your old and outdated prefixes for free
  • You can run it in the browser
  • PostCSS is the entry point to an awesome CSS developer experience’

What more could you want?