This material was originally published on Codica Blog, as part of the article The Power of CSS Processors in Web Applications Development.
Post-processors became an important aspect of CSS workflow. They allow front-end developers to improve and tweak the existent CSS. The first post-processor that comes to our mind is PostCSS. It is often used to transform CSS styles with JavaScript plugins.
At Codica, we firmly believe that post-processors can help developers improve the quality of writing in style sheets.
It is up to you to decide whether to use plugin Preset Env and CSS Modules or not. The plugin makes modern CSS compatible with most browsers. In their turn, CSS Modules can solve the issue of the so-called global scope relevant to CSS.
At the same time, we cannot do without code linting and adding vendor prefixes to support cross-browser compatibility. They are must-haves for a complicated web project.
Why use Post-processors in web applications development?
Benefits
Post-processors speed up the web app development process, make the code more readable and solve cross-browser compatibility issues. If you need to add support for some properties, use @mixin to add prefixes to them. In this example, we add mixins to the transition property which allows us to declare reusable styles without code duplication:
@mixin transition($args...) {
-webkit-transition: $args;
-moz-transition: $args;
-ms-transition: $args;
-o-transition: $args;
transition: $args;
}
Drawbacks
However, this approach is not perfect. It adds prefixes to all browsers even if Internet surfers don’t use them.
Luckily there is PostCSS with plugin Autoprefixer to save the day. This plugin automatically adds prefixes browsers in CSS. The results are avoided code duplication, reduced number of manual operations and time-saving.
Let’s discuss Autoprefixer and other plugins:
PostCSS plugins and tools
Autoprefixer
GitHub offers the following description of Autoprefixer:
“PostCSS plugin to parse CSS and add vendor prefixes to CSS rules using values from Can I Use. It is recommended by Google and used in Twitter and Alibaba.”
The developers also focus on the fact that “Autoprefixer uses Browserslist, so you can specify the browsers you want to target in your project with queries like > 5%”.
This is a partial solution to the cross-browser compatibility issue. We rely on global statistics that differ depending on the region.
Let’s see what Autoprefixer developers mention in this regard on GitHub:
“If you want to change the default set of browsers we recommend to combine last 1 version, not dead with > 0.2% (or > 1% in the US, > 1% in my stats). last n versions adds too many dead browsers and does not add popular old versions. Choosing a percentage above 0.2% will, in the long run, make popular browsers even more popular. We might run into a monopoly and stagnation situation, as we had with Internet Explorer 6. Please use this setting with caution.
Opera Mini has 100 million users in Africa and it is more popular in the global market than Microsoft Edge. Chinese QQ Browsers has more market share than Firefox and desktop Safari combined.”
Browserslist
In theory, we should fix on an end-user. Browserslist provides us with this possibility thanks to Browserslist-ga. This package gathers statistics from Google Analytics and keeps it in the JSON file used in Browserslist.
There’s a detailed guide on how to use this tool on the Browserlist-ga page:
“In the root directory of your project run: npx browserslist-ga
(npx comes with npm 5.2+, for older versions run npm install -g browserslist-ga and then browserslist-ga)
(to run the latest code directly from GitHub, execute npx github:browserslist/browserslist-ga instead)
You will be asked to log in with your Google Account. Your access token will only be used locally to generate a browserslist-stats.json file in the root of your project. After finishing the steps, you can use your stats with Browserlist by adding the following to your Browserslist config:
> 0.5% in my stats # Or a different percentage
Note that you can query against your custom usage data while also querying against global or regional data. For example, the query > 1% in my stats, > 5% in the US, 10% is permitted”.
At long last, we have “clean” CSS with browser support, based on the statistics of visits to our site.
As it is stated on Browserlist-ga page:
“All the praise goes to the humans and martians that develop and maintain Can I Use and Browserslist”.
CSSNext
CSSNext is PostCSS plugin that allows using the latest CSS syntax. For instance, you can easily use new custom properties without bothering about browser support.
Stylelint
Finally, there is Stylelint. It is a CSS linter for proofreading and validating the CSS code. It leaves less room for mistakes and helps you follow consistent coding conventions.
Conclusion
Now you get a better understanding of the role of CSS post-processors in web application development. We hope that examples from our practice demonstrate all the power of the mentioned tools.
Stay tuned and read about Sass: CSS With Superpowers.
Check our full article: The Power of CSS Processors in Web Applications Development.
Top comments (0)