Mastering PostCSS for Web Design: Explore the power of PostCSS to write highly performing, modular, and modern CSS code for your web pages

A question: what do SASS, Stylus, Haml, and Less all have in common?

The answer is, they are all compilers, source to source compiling, or transpilers (to give them their official name), that have been around since the 1980s. They have appeared in many different formats, with Digital Research's XLT86 being one of the earliest versions, dating from 1981.

More recently, the well-known SASS processor arrived in 2006; this was followed by Less, created by Alexis Sellier in 2009. Both work in a similar fashion: they take a set of rules and compile it into valid CSS. We can extend CSS with all manner of features, such as variables, mixins, functions, and more. Although processors may not help cut down the physical number of lines we have to write, they help us reorganize code into more manageable blocks that we can reuse in future projects, which helps make CSS easier to maintain.

But, as is nearly always the case, there are some drawbacks to using processors:

Hmm, this doesn't make processing so attractive! But what if there were a way to alleviate all of these issues, and remove the need for dependencies at the same time?

Well, there is: let's build our own processor! Okay, this might sound a little crazy, but as someone once said, there is method in this madness, so bear with me while I explain why this may be a better option.

At the beginning of this chapter, I mentioned that we would focus on creating our own preprocessor, right? Well, I have a little confession to make: we're not. Hold on, what gives?

Well, we will create a preprocessor…but we will also create a postprocessor too. Let me explain why—our alternative "option" allows us to create both at the same time. Our alternative option is PostCSS, which can be downloaded from https://github.com/postcss/postcss. PostCSS is used by some major companies, such as Twitter, Google, Bootstrap and CodePen, and even WordPress (in a limited capacity).

PostCSS was built as a Node.js module, so will work with any number of the existing plugins already available for Node.js—we will be using a number of these plugins throughout the book. Let's take a moment to explore some of the benefits of this tool.

Preparing for exercises in this book

Before we do so, we just need to cover a couple of requirements. First, we need to set up a local web server. It's not critical, but gives a better effect. I personally use WAMP Server (for PC, from http://www.wampserver.com/en), otherwise, Mac users can try MAMP (http://www.mamp.info/en), or the cross-platform Apache web server (from http://www.apachefriends.org). In each case, default settings should be sufficient.

The second requirement is to set up a project area; assuming you have set up a WAMP as a local web server, go ahead and set up a folder called postcss in c:\wamp\www, as shown in this screenshot:

Right, with that out of the way, let's make a start on getting PostCSS installed!

The first step on our journey is to get PostCSS installed—this runs from Node.js; we can use any one of several task runner plugins to install it. For the purpose of the exercises throughout this book, we will use Gulp; if you prefer, alternatives such as Grunt or Broccoli can be used.

Let's make a start with installing Node and Gulp:

We now have Node configured and an empty package.json file in place, so let's add our dependencies. We will start by adding Gulp first:

Once completed, Gulp is now ready for use; we can go ahead and install PostCSS.

PostCSS is a fascinating tool; its modular architecture leaves it wide open to being used in a variety of different use-case scenarios, or even a mix of several! Throughout this book, we'll touch on different uses, before bringing them all together to create a processor that can both pre- and post-process files within the same workflow.

To give you a taste of how well it works, we're going to build a simple processor now; this will automatically add vendor prefixes and spit out minified versions during compilation.

Let's make a start, we've installed the relevant plugins, so let's go create our Gulp task file:

Perfect, we now have a working PostCSS installation; any time we need to add vendor prefixes, we can just fire up our compilation process, and away we go…

Creating minified style sheets

A key part of producing style sheets is minifying the output; this should feature as standard in any developer's workflow. Minifying the results will cut down on bandwidth usage. In an age of broadband or cable use, this is less critical for smaller sites, but should not attract any less importance than for larger sites!

Thankfully, minifying files is a cinch to achieve when working with PostCSS. For this next exercise, we will use the cssnano and gulp-rename plugins, available from http://cssnano.co/ and https://github.com/hparra/gulp-rename, respectively. Let's go ahead and get them installed:

1. We'll start by firing up a Node.js command prompt, then entering the following and pressing Enter:

   npm install -–save-dev cssnano
   npm install -–save-dev gulp-rename
   

   Don't close the session window, we will use it later in this exercise.

2. Switch to the gulpfile.js file we created earlier (it's stored at the root of our project folder), then add the following lines immediately after the last closing }) on or around line 12:

   gulp.task('rename', ['styles'], function () {
     return gulp.src('dest/example.css')
      .pipe(postcss([ cssnano ]))
      .pipe(rename('example.min.css'))
       .pipe(gulp.dest("dest/"));
   });
   
   gulp.task('default', ['styles', 'rename']);

3. At the top of the file, we need to add two declarations, otherwise our code will fail; go ahead and add the following two lines, as highlighted:

   var sourcemaps = require('gulp-sourcemaps');
   var rename = require('gulp-rename');
   var cssnano = require('cssnano');
   

4. Any sharp-eyed readers may now spot a problem—in the last line, we have a reference to styles, yet nothing is shown in the code for this! To fix it, we need to change our code. In line 8, change the line as shown:

   gulp.task('styles', function() {

5. Save the file, then switch back to the Node.js command prompt window and enter this command, followed by Enter:

   gulp
   

6. Gulp will now compile:

   

   If all is well, we should see the compiled output appear in the dest folder of our project area:

   

In our project area, we not only have the source map file created under maps, but now also have a minified style sheet, the latter created by renaming the output from cssnano (cssnano does not do this renaming natively, hence use of the rename plugin).

Unfortunately though, we still have one small issue—take a look at the contents of the maps folder: notice anything? Hopefully, you may spot that the source map file is there for the uncompressed version of our style sheet, but not the compressed one! Let's fix that now. To do so, we just need to use the rename task in our Gulp file, as shown:

    .pipe(rename('example.min.css'))
    .pipe(sourcemaps.init())
    .pipe(sourcemaps.write('maps/'))
    .pipe(gulp.dest("dest/"));

Try running Gulp now. If all is well we should see the source map appear for our minified style sheet:

Let's finish off our gulp file; the last stage is to add a watch facility, so that changes are compiled automatically as soon as files are modified.

Altering to compile automatically

Adding a watch facility is simple when using Gulp. It helps reduce the manual effort required when using Gulp, as we only need to fire off the Gulp task file once, and it will continue to apply the tasks each time files are changed.

Unlike other plugins, we don't need to install any plugins for this; simply add the highlighted lines from the following to the gulpfile.js file:

gulp.task('default', ['styles', 'rename', 'sourcemaps']);

var watcher = gulp.watch('src/*.css', ['default']);
watcher.on('change', function(event) {
  console.log('File ' + event.path + ' was ' + event.type + ',     running tasks...');
});

We can see the results of the addition to our gulp task file, and how it all comes together, in this screenshot:

At this point, we can save the file then re-run the gulp command as before; this time it will automatically recompile any file that has changed, from within the src folder. In this instance, we've added an event handler to log an indication into the session so we can tell what is happening; we can easily modify this if needed.

We now have a basic working system; we will begin to add to this over the next few chapters, toward building up our own processor. There is one small thing we should cover though: it's not essential, but a useful tip for developing with PostCSS. I'm talking about linting your code, to ensure it is valid; let's dive in and get this set up for use.

It goes without saying that linting code should be part of any developer's workflow. There are lots of different ways to achieve this, depending on the tools you use. The beauty of PostCSS is that we can easily add a suitable linting capability to our processor, using the stylelint plugin for PostCSS (available from http://stylelint.io/).

Why would we do this? Easy: we can get a single consistent result throughout. This becomes essential if you work as part of a team; instead as different team members using inconsistent settings, we can set up a central point for processing, to retain a consistent output. Moving the linting process to our central workflow means the server can do the grunt work for us, and provide a consistent result anytime for anyone running the process.

With this in mind, let's take a look at how we can set up our linting capability:

It shouldn't take much effort to spot that #fff1az is clearly not a valid number! Stylelint has correctly identified it, using the highlighted rule from our configuration:

    .pipe(postcss([ stylelint({ 
        "rules": {
          "color-no-invalid-hex": true,
          …
        }
      }),

Let's explore how this plugin works for a moment—the great thing about it is that there are simply dozens of rules available (which you can see at https://cdn.rawgit.com/stylelint/stylelint/1.0.0/docs/rules.md). It works by concatenating together what is being checked (in this case, color) and the check being run against it (in our case, -no-invalid-hex, or checking for invalid hex numbers). We can apply any number of rules in our configuration object, to ensure that the output is consistent for all projects.

Okay, let's move on: we will begin to look at compiling code in more detail from the next chapter, but for now, let's take a look at how PostCSS works in more detail, and how we can begin to make the move from our existing processor to PostCSS.

So far, we've covered the basics of setting up and using PostCSS. It's worth taking a moment to learn about how it works, to better understand how we can use it and develop our own plugins for the platform.

PostCSS is like me on a Saturday morning after a good night out: it does nothing! Yes, it's true, by itself, the application doesn't do anything at all; it's when we add plugins into the mix that it starts to become useful.

The key to PostCSS is treating it as an enabler, it is not meant as a direct replacement for your existing preprocessor, or even postprocessor, but to complement them. It works on the basis of parsing code, processing it with any assigned plugins, and rendering the results:

It works by parsing content into an Abstract Syntax Tree (or AST) with a series of nodes. Each node in the tree contains a symbolic representation of an element in your code. In other words, if you had a condition statement that pointed to three possible outcomes, then the AST would have a single node, with three branches representing the possible outcomes.

Our AST is then sent through one or more plugins (we must always use one plugin, but can have many in our gulp file). It then converts the code to a long string, before processing it through any assigned plugins and spitting out the result in the form of valid CSS. We can use this as a basis for creating our own plugins, using the boilerplate code and API that are both available from the main PostCSS site on GitHub.

The trick to the plugin stage is in the mix of plugins we must use to satisfy our needs; the better ones should only perform one role. Any that perform multiple tasks are less ideal, as they are likely to contain excess functionality that we don't need in our projects.

Writing valid CSS is an art that has been present since the dawn of the Internet; this takes skill, patience, and time to produce and perfect any masterpiece. Processors such as SASS or Less have helped to make the process more efficient, but are not without their drawbacks; PostCSS allows for a more customized approach, but without the extra baggage. We've covered a few key points around PostCSS throughout this chapter, so let's take a moment to review what we've learned.

We began with a brief look at the art of processing, before introducing PostCSS as a tool. We then explored some of the benefits and drawbacks of using it, and how it can fit in seamlessly with your existing development workflow, with a little careful planning.

Next up, we covered the installation of PostCSS along with Gulp as the task runner/host process, before embarking on a simple demo to introduce how the compilation process works, and that with the right choice of plugins, we can take out some of the manual grunt work required to manage our code (pun intended!). With our code compiling, we then turned our attention to adding a watch facility, and automatic support for linting our code, to ensure we maintain consistent standards.

We then rounded out the chapter with a look at how PostCSS works, and understanding something of its architecture, so that we can begin to make the move from using plain CSS or an existing preprocessor, to using PostCSS.

Phew, we've certainly covered a lot; it's time to really get stuck in now, and start to use PostCSS in earnest. Over the next few chapters, we will explore a number of different concepts that are common to existing preprocessors, and explore how we can benefit from making the transition to using PostCSS. We have to start somewhere, so we'll kick off with using variables, functions, and mixins in the next chapter, and see how we can use some of the techniques from processors, but without the associated baggage!