PostCSS Preset Env: Babel for CSS

PostCSS has been my personal favorite out of all the tools (or flavors) for writing CSS for the past year and a half. Setup is really easy, it features tons of extremely useful plugins and it has great performance. One of my favorite plugins is definitely postcss-preset-env.

What is postcss-preset-env?

Basically, it’s Babel for CSS. It allows developers to write CSS using modern and future syntax and transpiles that code to CSS which is widely supported by most browsers. Sounds simple, right?

For example, this allows developers to use CSS variables in their regular CSS code. Depending on the config, postcss-preset-env includes regular values alongside CSS variables as fallback for browsers that do not support CSS variables.

Code

.cta:hover {
  background-color: var(--color__cta--darker);
  color: var(--color__secondary);
}

Result

Installation

1. Install it using npm: npm install postcss-preset-env --save-dev
2. Add it to your PostCSS plugins config: gulp, webpack, postcss config file, etc. For example, in postcss.config.js we can include it like this:

module.exports = {
  plugins: {
    "postcss-preset-env": { /* Options */ },
  }
}

With default config, postcss-preset-env uses Stage 2 CSS features (which we’ll explain later) and targets all browsers (if no browsers option is set in the project).

Basic Configuration

I want to cover only the most used and most important config options, and those are stage, features and browsers. You can check the list of all options in the docs.

Stage

This is similar to ECMAScript proposals used in Babel. The stages represent the steps that each feature (or proposal) in CSS must go through to become a part of the CSS standard. It consists of the following stages:

• Stage 0: Aspirational - an idea or an early draft. Highly unstable and subject to change
• Stage 1: Experimental - also highly unstable and subject to change, but the proposal is recognized by the members of W3C.
• Stage 2: Allowable - also highly unstable and subject to change, but it’s actively being worked on.
• Stage 3: Embraced - stable and subject to little change. This feature will likely become a standard.
• Stage 4: Standardized - final working solution. supported by all major browsers.

By setting a stage option, we are choosing groups of CSS features that we can be used when writing CSS:

    "postcss-preset-env": {
      stage: 3
    }

Useful links for keeping track of which CSS features are in what stage:

• https://cssdb.org/
• https://preset-env.cssdb.org/features

Features

We can use the feature config to only enable specific CSS features, regardless of which stage option has been set.

All feature variables can be found here: https://preset-env.cssdb.org/features

In the following example, we use all stage 3+ features and we include nesting-rules feature which is a stage 1 feature.

    "postcss-preset-env": {
      stage: 3,
      features: {
        "nesting-rules": true
      }
    }

Browsers

This is a standard Browserlist config that is being used by various tools and plugins like Autoprefixer.

In the following example, we are only targeting the last 2 versions of the browser.

    "postcss-preset-env": {
      browsers: "last 2 versions",
      stage: 3,
      features: {
        "nesting-rules": true
      }
    }

Full config and docs

These several options are more than enough to get you started with using postcss-preset-env and write modern CSS syntax that transpiles down to widely-supported CSS syntax. For the full list of config options and features, you can check the following links

• https://github.com/csstools/postcss-preset-env
• https://preset-env.cssdb.org/

Thank you for taking the time to read this post. If you've found this useful, please give it a ❤️ or 🦄, share and comment.