CSS pre-processing is a concept that most web developers have already learned or read about. We’ve covered CSS preprocessing in great detail to help developers get up to speed on this prevalent technology. But what about post-processors?
These relatively new tools are similar in the sense that they affect the web development workflow, however they operate on the other side of CSS development (“post” development).
In this post, I’d like to introduce the basics of post-processing, how it works, why you’d use it, and share a few libraries/tools you can use to up your CSS game with post-processing.
Read Also: Getting Started with Sass
Post vs. pre-processing
The pre-processing revolution happened when Sass/LESS hit the scene. These tools allow developers to use variables, loops, functions, and mixins within CSS. This almost makes basic CSS development similar to a programming language with extended functionality.
Post-processing happens after you already produced the plain CSS, and want to extend it further through automation. This can include extending class selectors, or auto-appending prefixes for certain CSS properties.
Here’s a quote from a post which is also the source of the image above. I think the author Stefan Baumgartner sums the difference up brilliantly.
“[Preprocessors] take a language that compiles to CSS. And [Postprocessors] align and refurbish CSS to have the best possible outcome for today’s browsers.”
In a way, both of these seem like automation tools, just working in different ways. For instance, a common pain solved by post-processing is to auto-append prefixes for newer CSS3 properties.
But this can also be done in Sass with extensions. So is there really a difference? Here’s another great quote from the same post:
“Pre-processors” and “post-processors” don’t exist. They are CSS processors taking care of both authoring and optimization features.
While this may be true in a theoretical sense, the web development community still creates a divide between these tools. For this reason, I would highly recommend to frontend developers to at least read about post-processors and to know what they can do.
Fit post-processing into your workflow
Almost everyone references PostCSS as the definitive resource for post-processing. However the PostCSS team has openly admitted on Twitter to changing their title because the verbiage doesn’t quite make sense anymore.
PostCSS is no longer just a pre-CSS or post-CSS tool. It can actually work in both areas! This further explains the quote from earlier stating that all CSS tools boil down to one thing — processing.
To build your own pre/post CSS processing workflow, start by making a list of your pain points, such as:
- auto-prefixing CSS gradients
- auto-organization for CSS rules
- appending polyfills for certain properties
- generating image dimensions for background images
Note that all of these things can be done in both pre and post-processing. It’s important to realize that CSS pre/post-processing is quickly merging to become one in the same thing.
Instead of breaking down your goals into different stages of processing, it’s better to list them as objectives, then go on a search for the right tools.
Best post-processing tools
I’ve tried to avoid mentioning extensions in this section, as Sass & PostCSS has so many things to choose from. Honestly you could get by with just those libraries, but I also want to offer some alternatives for more specific solutions.
I remember when Internet Explorer 6 was still a nuisance, and it’s nice to know IE development has improved — but not by much. While I’d love to tell you IE usage is basically gone, this just doesn’t seem to be true.
Thankfully, Bless CSS is a solution that detects potential IE-related problems in your CSS, and creates solutions with post-processing. It runs on Node.js, so it fits well into the typical NPM/Gulp workflow.
Here’s a really cool library that allows you to build CSS with more advanced functionality that’s currently not supported. The CSSNext library includes support for odd CSS4 functions, such as
gray(), that are currently only present in W3C drafts.
I don’t think every developer will need this library. It’s very specific, and won’t solve day-to-day problems, however it can give you a taste of upcoming CSS4 specs while converting the syntax down to modern CSS3.
If browser support is an issue for you, then Stylecow is a necessity. This powerful library allows you to develop CSS just for your favorite browser. Then, you can run the command line tool through Node, and your CSS will be updated for all browsers you want to support.
Lastly I want to share the
-prefix-free library that’s also a beloved tool for CSS development, as it allows you to use unprefixed CSS properties. Everyone wants to use modern CSS properties, such as animations & gradients, but nobody wants to copy/paste verbose code manually.
With this plugin, you don’t even have to run your CSS through a postprocessor on your computer. It can also work as a browser include that runs on the user’s computer to automatically update CSS files.
Autoprefixer, which is part of the PostCSS library, is probably even a better choice for local post-processing. That’s why I said before that if you use either LESS or Sass along with PostCSS, then you’ll have everything you need for an impressive CSS development workflow.
Post-processing is more of a catchphrase than a real technology, although it does have its place in the CSS workflow, as the entire process of writing modern CSS has been dramatically enhanced by these tools. I can only recommend that developers dig deeper to find whatever works best for them.
If you’re looking for even more info on post-processing, take a peek at these related articles: