PostCSS

Updated on Jan 29, 2024

Edit

Comment

Development status Active		Written in JavaScript

Developer(s) Andrey Sitnik, Ben Briggs Initial release November 4, 2013; 3 years ago (2013-11-04) Stable release 5.2.14, Duke Vapula / February 17, 2017; 18 days ago (2017-02-17) Repository github.com/postcss/postcss

PostCSS is a software development tool that uses JavaScript-based plugins to automate routine CSS operations. The tool has been used to develop the code of Wikipedia, Facebook, and GitHub. PostCSS is a top-favored CSS tool among npm users. It was designed by Andrey Sitnik with the idea taking its origin in his front-end work for Evil Martians.

Structure

Unlike Sass and Less, PostCSS is not a CSS-compiled template language but a framework to develop CSS tools. However, it can be used to develop a template language such as Sass and LESS.

The PostCSS core consists of:

CSS parser that generates an object tree (AST) for a line of CSS-code;

Set of classes that comprise the tree;

CSS generator that generates a CSS line for the object tree;

Code map generator for the CSS changes made.

All the useful features are made available through plugins. The plugins are small programs working with the object tree. After the core has transformed a CSS string into an object tree, the plugins, by turn, analyze and change the tree. Then the PostCSS core generates a new CSS string for the plugin-changed tree.

Usage

Both the PostCSS core and the plugins are written in JavaScript and distributed through npm.

PostCSS offers API for low-level JavaScript operations:

There are official tools making it possible to use PostCSS with build systems such as Webpack, Gulp, and Grunt. There is also a console interface available for download. Browserify or Webpack can be used to open PostCSS in a browser.

Syntaxes

PostCSS allows changing the parser and generator. In this case, PostCSS could be used to work with the Less and SCSS sources. However, PostCSS on its own cannot compile Sass or Less to CSS. What it does is change the original files — for instance, by sorting the CSS properties or checking the code for mistakes.

Besides, PostCSS supports SugarSS, a syntax not unlike Sass and Stylus in its simplicity and succinctness.

Plugins

The number of PostCSS plugins amounts to more than 300. PostCSS plugins can solve most CSS processing tasks ranging from analysis and properties sorting to minification. However, the plugins significantly vary in quality and popularity.

The complete plugin list can be found on postcss.parts. Below are a few examples, with the what-fors explained:

Autoprefixer to add and clear browser prefixes. It is the most popular PostCSS plugin. According to the SitePoint polling[26], 56% of respondents used Autoprefixer in March 2016.

CSS Modules to get CSS selectors isolated and code organized. It is supplied as part of the popular bundler Webpack.

stylelint to analyze CSS code for mistakes and check style consistency. It is used by Wikipedia, Facebook and GitHub. Another plugin, stylefmt fixes the CSS code according to the stylelint settings.

PreCSS to perform some Sass/Less preprocessing functions.

postcss-cssnext to emulate features from unfinished CSS specification drafts. Used by Wikipedia.

cssnano to make CSS smaller in size by getting rid of the spaces and rewriting the code succinctly. Used by Webpack, BBC, and JSFiddle.

RTLCSS to change CSS code so that the design should be suitable for right-to-left writing (such is applied in Arabic and Hebrew). It is used by WordPress.

postcss-assets, postcss-inline-svg and postcss-sprites to work with graphics.

There are a number of tools expanding their functionality by PostCSS. For example, it is PostCSS that the popular bundler Webpack uses to work with CSS.

Criticism

Despite certain plugins having faced criticism, some PostCSS plugins have become de facto standard. For instance, Google recommends using Autoprefixer to solve the problem of browser prefixes in CSS.

The industry opinion of PostCSS is highly positive, it going as far as Sass developers considering PostCSS a good addition to Sass.

The biggest question is whether PostCSS plugins should be the only option to use when making a CSS build system. On the one hand, PreCSS or cssnext can perform many Sass and Less functions, with SugarSS possibly being a good replacement for the minimalistic syntax of Sass and Stylus. On the other hand, some experts, including the PostCSS creator himself, recommend sticking to Sass and Less for legacy projects.

Advantages

Features. Many PostCSS plugins one of a kind, PostCSS is often used as an addition to Sass and Less.

Unification. PostCSS plugins cover most CSS building tasks from checking the code for mistakes to minification. As a result, all CSS tools can share the same parser, architecture, and development tools. PostCSS allows for better performance by making all the plugins use the same object tree — in contrast to the common practice of each tool creating one of its own.

Modules. The user is free in their choice of PostCSS plugins and can switch off the unnecessary ones for faster performance. With different plugins solving the same problems, the user can choose whatever best fits their needs. The PostCSS creator believes that the higher number of plugins compete for the user’s attention, the better they will eventually become.

Speed. PostCSS is equipped with one of the fastest JS-based CSS parsers. It is up to twenty times faster than Ruby Sass and four times faster than Less in doing basic preprocessing. However, real efficiency highly depends on the number of the plugins installed. In fact, the PostCSS creators themselves have confirmed that modern preprocessors work too fast for a speed up to be noticeable.

Disadvantages

Difficult to configure. Some developers tend to avoid the burden of choosing plugins and tuning them up to work together. Ready-made plugin sets are only a partial solution to the problem.

Non-standard syntax. With each project using its own plugin set, a new developer might not understand that the function unknown is related to the unpopular PostCSS plugin. It is recommended to indicate file plugins with postcss-use, but some people find it unnecessary.

Selectors and values using separate parsers. PostCSS saves CSS selectors and property values as lines without further parsing them. To parse them, plugins have to use extra parsers. The PostCSS team is going to fix this in future versions.

Sequential processing. With the object tree being able to respond to only one plugin at a time, having a number of plugins might result in lower performance. Besides, there are functions no plugin can process. The PostCSS team is going to fix this in future versions.

History

Born in the course of the Rework project, the idea of modular CSS processing was suggested by TJ Holowaychuk September 1, 2012. February 28, 2013, TJ expressed it in public.

March 14, 2013, Andrey Sitnik’s front-end work for Evil Martians resulted in Autoprefixer, a Rework-based plugin. Initially, the plugin name was rework-vendors.

As Autoprefixer grew, Rework could no longer to meet its needs. September 7, 2013, Andrey Sitnik started to develop PostCSS based on the Rework ideas.

In 3 months, the first PostCSS plugin, grunt-pixrem was released. December 22, 2013, Autoprefixer version 1.0 migrated to PostCSS.

For PostCSS, the primary style focus is alchemy. The project logo represents the philosopher's stone. Major and minor PostCSS versions get their names after the Ars Goetia demons. For instance, version 1.0.0 is called Marquis Decarabia.

The term postprocessor has caused some confusion. The PostCSS team used the term to show that PostCSS was not a template language (preprocessor) but a CSS tool. However, some developers think the term postprocessor would better suit browser tools (for instance, -prefix-free). The situation has become even more complicated after the release of PreCSS. Now, instead of postprocessor, the PostCSS team use the term processor.

References

PostCSS Wikipedia

(Text) CC BY-SA

Contents