You can download the example code files for this book from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

You can download the code files by following these steps:

You can also download the code files by clicking on the Code Files button on the book's webpage at the Packt Publishing website. This page can be accessed by entering the book's name in the Search box. Please note that you need to be logged in to your Packt account.

Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:

The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/Mastering-PostCSS-for-Web-Design. We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

We also provide you with a PDF file that has color images of the screenshots/diagrams used in this book. The color images will help you better understand the changes in the output. You can download this file from http://www.packtpub.com/sites/default/files/downloads/MasteringPostCSSForWebDesign_ColorImages.pdf.

Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.

To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.

Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.

Please contact us at <copyright@packtpub.com> with a link to the suspected pirated material.

We appreciate your help in protecting our authors and our ability to bring you valuable content.

If you have a problem with any aspect of this book, you can contact us at <questions@packtpub.com>, and we will do our best to address the problem.

What do we mean by PostCSS? In a nutshell, it can be used to refer to one of two things—the PostCSS core tool or the plugin ecosystem that is powered by the tool. On its own, it doesn't actually do a lot; once we start adding plugins, we can achieve a great deal. Let's explore what this means in practice:

Well, there are some considerations to using a custom processor; the key thing to remember is that PostCSS is neither a pre- nor post-processor, but more of a Swiss Army Knife of a toolbox that we can use to process our CSS code. Let's take a look at some of these drawbacks:

You already develop sites using a preprocessor such as SASS. You can compile code using a standalone processor, but normally prefer to use Node.js and Gulp to complete the task. Sound about right? What about making the move to using PostCSS?

No problem, we can include a section for processing CSS files using PostCSS. The key here is to not use PostCSS to perform the initial compilation, but to perform the post-processing, such as adding vendor prefixes or minifying the results. Once this is established, we can start to incorporate some of the plugins available for PostCSS that allow us to replicate functionality, such as from within SASS. Once we've adjusted existing code to use the format required by the plugins, we can then switch to using PostCSS, and begin to remove our dependency on using SASS.

At this point, it is worth spending a few minutes to help clear up some common misconceptions about PostCSS, although many associate it as being a preprocessor, or even a postprocessor, this isn't what was intended:

Okay, let's move on, I think it's time for less chat and more action, right? Let's get stuck in to producing something; there's no better time than now to get PostCSS installed and ready for use.

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!

We're at the interesting stage now—installing PostCSS. PostCSS is available from https://github.com/postcss/postcss, and can be installed into Node using a Gulp plugin. Let's do that now:

On its own, PostCSS doesn't do anything; to make it more useful, we are going to install three plugins. We will explore using plugins in greater detail later in the book, but for now, don't worry too much about what is happening:

PostCSS is now installed for use, but if we try to use it, we probably won't get very far, as it needs to be configured for use! Let's take a look at doing that now, by creating a simple example that will add vendor prefixes to some sample CSS rules, and automatically minify the results.

Or do we? Ah, there is much more to PostCSS than simply adding vendor prefixes! Remember how I mentioned that PostCSS is often (incorrectly) labelled as a pre- or post-processor?

Well, there is much more we can do; one of the key benefits of PostCSS is being selective about how we process our code. We're not forced to rely on dependencies (such as Ruby for SASS); we can instead produce something that is very light and quick. In our previous example, we created a task called styles; we'll change this to use the task name default, which will allow us to run multiple tasks from one command. This means we can simply call gulp, instead of needing to supply the task name.

Let's put this to the test and start to expand on our compilation process by adding source map support—we'll use the source map plugin for Gulp by Florian Reiterer, available from https://github.com/floridoo/gulp-sourcemaps:

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:

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.

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.

Assuming we decided to use PostCSS, there is almost always one question at the top of everyone's mind: how do we make the move?

In short, the key here is not to simply assume existing code can be put through the PostCSS process, as it will likely not work. Instead, we should take an iterative process, and begin to convert low-hanging fruit to using PostCSS. The process will of course require some work, but there are tips on how we can reduce the pain involved in making the switch to PostCSS.

The key to making the transfer is to work out what functionality needs to be processed, then to create the initial framework for a build process (for example, a Gulp or Grunt task file), then to gradually add in plugin support one by one, until you have a fully working compiler.

We can take this a step further, and use plugins that replicate SASS code format into PostCSS; an ideal plugin to start with is Autoprefixer, followed by plugins such as postcss-mixins or postcss-partial-import. We will explore using SASS as a basis for a custom syntax in Chapter 11, Manipulating Custom Syntaxes, where we will use these two plugins, and more, to help make the transition process easier and help remove the dependencies on preprocessors such as SASS or Less. Oh, and above all, being based on JavaScript makes it portable; what more could a developer ask for, I wonder?

Okay, on we go. Over the course of the next few chapters, we will take a look at different processor elements that are commonly used to create build processors, such as variables or mixins. We'll see how they might typically be written in processors such as SASS or Less, then work on converting our code to use PostCSS equivalents before processing to produce valid CSS. We will then finish up with pulling everything together to build your own custom processor for use in future projects.

A copy of this demo using the equivalent code from the Less CSS pre-processor is available in the code download that accompanies this book. It's in the Tutorial1B folder if your preference is to use the Less CSS pre-processor; you will need to install the gulp-less plugin from https://github.com/plus3network/gulp-less, using NodeJS (in the same manner as other plugins that we've installed). An updated copy of the Gulp task file is also included in this folder, along with completed versions of the CSS code.

Over the last few pages, we've created a simple demo, which shows off animated information boxes for a couple of orchid images. There's nothing outrageous or complex about what we've done, but nevertheless, it serves to illustrate some key points about using this plugin, and PostCSS in general:

In short, we create a reference to each variable within the configuration object for cssvariables, as the alias for the postcss-css-variables plugin.

Creating an object map using this approach can have mixed benefits. For some, it reduces issues around separation of concerns, where we can keep more PostCSS code within the task file, and less within our style sheet. This can make for a task file that is harder to read; it's not a good route to take if you have lots of variables to define. In this instance, we would be better off exporting them to an import file and referencing them at compilation.

If there is one important message at this point, it can be that of flexibility—the modular nature of PostCSS means that we can be free to pick and choose how we proceed; it really is a case of weighing up the pros and cons of using a plugin, and making a decision as to whether this best fits our needs, or if we need to look for an alternative solution.

At this point we will have support for mixins within PostCSS installed. Let's make use of them by updating our gulp task file and style sheet. We'll begin with the gulp task file:

Although our demo won't appear any different, there will be a noticeable difference in the code—a quick peek using a DOM inspector such as Firebug shows the use of rem values:

The use of mixins does raise some important points. Indeed, one might be forgiven for thinking they simply replicate functionality from SASS. The plugin we've used does not follow the same format, even if the principles are the same; let's pause for a moment and take a look at how these stack up against standard processors.

The use of mixins is a great way to automatically insert pre-defined blocks of code, either static or dynamic, into our stylesheet, at the compilation phase.

The key thing to note is that, although the end result may be similar, the similarity is just in name; the mixin plugin we've used was not designed to replicate existing functionality available within SASS. Instead, this plugin exposes the power of JavaScript within PostCSS, and should be used to define function mixins, as a replacement for if or while statements that are not available within PostCSS.

This is particularly true if we need to change any property names within the mixin; an example of this would be when referencing multiple images that each need similar style classes to be applied:

require('postcss-mixins')({
  mixins: {
    icons: function (mixin, dir) {
      fs.readdirSync('/images/' + dir).forEach(function (file) {
        var icon = file.replace(/\.svg$/, '');
        var rule = postcss.rule('.icon.icon-' + icon);
        rule.append({
          prop:  'background',
          value: 'url(' + dir + '/' + file + ')'
        });
        mixin.replaceWith(rule);
      });
    }
  }
});

If we were to call this mixin with @mixin icons signin; from our code, we would see this as a result:

.icon.icon-back { background: url(signin/back.svg) }
.icon.icon-secret { background: url(signin/secret.svg) }

This does pose an interesting question: where should the cut-off point between using JavaScript in our task file be, in comparison to our CSS? Taking this approach does mean that we have the benefit of using standard JavaScript, but at the expense of simplicity!

This is one of the decisions you will need to make as a developer. PostCSS's flexibility means that not only do we need to choose the right plugin, but that the order they are all called in can also have an effect on the outcome of our code. In this instance, an alternative plugin—postcss-simple-vars—shares the same syntax as postcss-mixins, but does not support changing of property names.

But, to bring it back to our example: we used the classic mixin for providing pixel fall-back when using older versions of IE.

We could have used an alternative plugin here, in the form of postcss-simple-mixins (available from https://www.npmjs.com/package/postcss-simple-mixin). This is designed to provide simple support for mixins, and doesn't have the baggage associated with postcss-mixins.

The key consideration, though, will depend on what you plan to achieve within your code; choosing the right plugin will reduce the inclusion of redundant functionality and help keep our custom processor as lean as possible.

There is another reason why choosing plugins is critical: instead of using a mixin to just support older versions of IE, we can use the postcss-pxtorem plugin to generate rem values during compilation. After all, although most browsers have supported rem units for some time, there is always one that is late to the party:

Screenshot taken from the CanIUse site, at http://www.caniuse.com

Switching to using this plugin has the added benefit of simplifying our code, as the server can handle the grunt work of replacing pixel values with the equivalent rem units. The grunt work can be shifted to a central location, so that anyone using it will receive consistent results.

Okay, onwards we go. Time to switch topics completely, and take a look at another key part of PostCSS: creating loops. Anyone familiar with SASS or Less will be aware of how mundane it can get when applying very similar styles to identical objects; a perfect example are the classic social media icons that frequently grace posts on a page. PostCSS has a plugin that allows us to mimic this functionality, so let's explore how to use it in action.

Staying with the looping theme, but on a different tack, in place of using the for statement, we can achieve similar effects with @each, but only if the target is an element on the page.

I am of course talking about elements such as buttons or menu items; these elements will share the same styling, but require unique IDs to allow us to interact with them. It goes without saying that we could simply create a shared base class and add multiple classes for each element…

But we can do better than that: most preprocessors have in-built functionality that allows us to iterate through elements and apply CSS styling to each element. Thankfully, PostCSS is no different; we can achieve the same result using the postcss-each plugin, available from https://github.com/outpunk/postcss-each. It's a cinch to install, and we can use it to add elements such as social media icons to the foot of a page, and style them. I feel a demo coming on, so let's dive in and take a look:

With the plugin now in place, let's move on and update our gulp file:

At this point, we can save the file. It is now ready for us to process the CSS required for our next demo. For this next exercise, we will need to avail ourselves of some suitable social media icons. I've used the ones by Nathan Brown, available at http://wegraphics.net/downloads/free-stained-and-faded-social-media-icons/. We'll use the Twitter, LinkedIn, and YouTube images.

Let's make a start:

If all is well, we should have three icons showing, when previewing the results in a browser. Nothing outrageous here: we have the base rule that applies to all of the icons, which is followed by the individual classes required to handle each icon itself:

.social-icon {
  background: 50% no-repeat;
  background-size: 100%;
  float: left;
  height: 50px;
  width: 50px;
}

.social-icon.twitter {
  background-image: url("../img/twitter.png");
}

.social-icon.linkedin {
  background-image: url("../img/linkedin.png");
}

.social-icon.youtube {
  background-image: url("../img/youtube.png");
}

So, how would this look in PostCSS? Well, surprising as it may be, there isn't a great deal of change needed.

We only need to change it in two places within our CSS file. I've also separated the nested code, to make it easier to view:

.social-icon {
  // shared information here
  background: 50% no-repeat;
  background-size: 100%;
  float: left;
  height: 50px;
  width: 50px;
}

The changes we need to make are highlighted in this block of code:

@each $media in twitter, linkedin, youtube {
  . $(img) {
    background: url('../img/$(media).png');
  }
}

Our gulp file also needs to change. Let's work through the steps involved to make the switch to PostCSS:

Granted, it is a simple exercise, but then I've always been a fan of keeping things simple! Anyone can write CSS styles, but for me the "step up" is knowing that quantity does not always beat quality, and that there is something to be said for following the KISS principle, Keep It Simple… Yes, you get the idea!

But, just to show how flexible this plugin is, try this as an exercise:

But, there is a catch: when the file has been compiled, check the file size. It should tell you that it is significantly larger than the one which doesn't contain data-URI equivalent code. This is to be expected: it's the trade-off between sizes versus the number of resources we call. It only shows how critical the order of our PostCSS plugins would be, to get the desired results!

For our demo, we will have four pages—the navigation will flip between each page, using standard CSS3 animation:

The design may be a little unique, but to help illustrate how it could be used, I've added a simple wireframe sketch to the front page, which could easily be expanded to the remaining pages and developed into something more substantial.

To see it in action, extract a copy of the Tutorial5 folder from the code download that accompanies this book, then run index.html in a browser, and click on the dots or arrow icons to the right—you will see it flip up or down, depending on which direction you click.

At present, our demo is using plain CSS, and nothing is wrong with this, but I suspect some of you will likely be using an existing processor, such as SASS or less CSS. The real benefit of using PostCSS is its ability to mimic existing tools, without the dependencies.

With this in mind, there are copies of the demo, available in the code download, which use Less CSS and SASS. If you prefer using SASS, then go ahead and extract Tutorial6A from the code download folder; for Less, use Tutorial6B. The code can easily be compiled using the gulpfile.js file from Tutorial1A in Chapter 2, Creating Variables and Mixins (for SASS), or Tutorial 1B (for Less CSS, in the same chapter folder).

Both will produce identical results to the vanilla CSS version, once compiled, and the contents of the dest folder have been copied to the css sub-folder in the tutorial folder. With the base demo in place, we are now ready to make the conversion—let's make a start by installing the postcss-nesting plugin.

Altering our code to use PostCSS is very simple. Even if it requires a few changes, the format does not change significantly when compared to processors such as SASS; let's take a look at what is involved:

Our style sheet is now converted; to prove it works, we need to run it through PostCSS, so let's do that now as part of the next exercise.

With the changes made to our code, we need to compile it—let's go ahead and do that now, using the same process we saw back in Chapter 2, Creating Variables and Mixins:

Try previewing the results in a browser—if all is well, we should see the same results appear as before, but this time using PostCSS, and without the dependency on SASS. We can now apply the same techniques to any project, safe in the knowledge that using the postcss-nesting plugin will allow us to compile to valid CSS code—or will it?

If, when working on code, we are forced to regularly use nested styles that are more than two or three levels deep, then there are some tricks we can use to reduce both the CSS specificity over time, and the need to use nesting more than two to three levels deep. Let's take a look at a few:

We've seen a number of ways of avoiding, or reducing CSS specificity issues that are inherent with nesting; the key message, though, is that we are not forced to have to nest our code, and that, to paraphrase the front-end architect Roy Tomeij—nested code doesn't create bad code; bad coders do!

There is one method, though, that we've not touched on, and for good reason: it's a route many developers new to using processing will likely take for the first time. Intrigued? It has something to do with using conversion tools, and more specifically, how we use them to convert from plain CSS to code suitable for compiling using PostCSS.

Imagine this scenario, if you will:

You've taken over a website, and are keen to make use of PostCSS to help with maintaining your code. The code uses plain vanilla CSS, so as a step to converting it, you happen to know of a number of sites that will convert plain CSS to SASS. After all, there are some similarities between PostCSS and SASS code, so why not?

You extract the results into a text file, save it, and put it through a SASS compilation process. Out comes some newly compiled CSS, which you drop into the relevant location on your server, and voilà! You have a working site that now uses SASS. A working site, and a perfect basis for converting to PostCSS…or is it?

The short answer should be no, but the longer one is that it will depend on your code. Let me explain why:

Simply pushing code through a conversion process isn't enough—granted, it will give you code that works, but unless it is very simple, it is likely not to give code that is concise and efficient. To see what I mean, take a close look at the CSS style sheet from Tutorial5—and specifically, the style rules for .nav-panel, from around line 132.

A conversion process will have no problem processing it to produce valid SASS, but it won't look pretty—as an example, try copying lines 114 to 197 into the converter hosted at http://css2sass.herokuapp.com/. Doesn't look great, does it? There is definitely room for improvement—I've already made some changes to the code, but we can do more; let's take a look at what can be done to improve the code.

When using a CSS to SASS convertor, the one key point that should always be at the back of our minds is that the converted code should not be considered the final article.

It doesn't matter how simple or complex your code is—it should be the first step in our conversion process. It's just a matter of how little or how much we have to do, once the code has been through the converter! As an example, take a look at this block of code:

It's a direct copy of lines 234 to 239 of the compiled version of the pen by Nikolay, which we used as a basis for our earlier demos. Now take a quick look at the equivalent code that I tweaked from the original and used in my version:

Notice any differences? The vendor prefix version of the transform attribute has been stripped out—most modern browsers (certainly within the last year to eighteen months), should handle this code without the need for vendor prefixes. The original version also suffered from a high degree of CSS specificity—this will become even more apparent if the code is nested!

To improve it, I've switched in .nav-panel ul li as a direct replacement for .nav-panel ul .nav-btn—the code is relatively simple in that it does not need a second class to identify elements for styling purposes. The next logical step is to break up the large nesting block within the source file; it is tempting to include a single large block, but this will be at the expense of readability, maintenance, and performance.

We could potentially go even further, and consider removing the leading .nav-panel; not only will it make the code infinitely easier to read, but it will also reduce the issues around CSS specificity. Of course, this kind of change will depend on what is in your code; the point here is to examine your code thoroughly, and look to reduce any CSS specificity as much as possible, so that your nesting won't look so bad!

There is an alternative means we can use though, which removes issues around CSS specificity—using Block Element Modifier notation (or BEM for short). It's a great way to systematically style elements using CSS, and it is worth taking time to get accustomed to how it works. Let's dive in and take a look.

For our BEM demo, we're going to work through the CSS rules required to show some simple message boxes on screen, such as for displaying confirmation that a task has completed, or a warning when something isn't right.

It's a simple demo, but shows off the principles behind BEM CSS perfectly—go ahead and extract a copy of the Tutorial8 folder, then run index.html to get a feel for what we will be producing. This version uses standard CSS; we will use this as a basis for converting to using BEM.

Let's make a start:

Our simple demo isn't going to set the world alight in terms of styling. If we were to preview it now, the results will of course not look great; let's fix that by setting up the compilation and linting tasks within PostCSS.

Our code is in place, but the boxes won't look particularly appetizing—most of the styles are still written using PostCSS @-rules. We can fix that by compiling the code, so let's dive in and take a look at installing support for BEM.

Setting up BEM support in PostCSS is a cinch—we can make use of two plugins to compile and lint our code. The plugins we need for this task are postcss-bem (available from https://github.com/ileri/postcss-bem), and postcss-bem-linter (available from https://github.com/postcss/postcss-bem-linter). Both can be installed using the same process through Node.js.

Hopefully the process will be familiar by now, so without further ado, let's make a start:

Now that the plugin is installed, we can go ahead and add support to our gulp task file, and begin to parse our code:

Our simple demo shows some useful message boxes that we can use as a basis for something more complex; it illustrates perfectly how we can use BEM to style our code, while keeping issues around CSS specificity at bay. We've covered a few useful techniques throughout this exercise, so let's take a moment to explore them in more detail.

The two errors are being caused by postcss-bem-linter, which is not recognizing the two styles as valid BEM notation. This raises a question: can we alter our code to remove the issues?

To answer this, we would need to weigh up how much code is affected against the time and effort required to alter it. In our demo, there is very little code affected; to resolve it, we would need to alter the .dlgBox and span styles to equivalent BEM naming.

Is this worth the effort? In a small demo such as ours, it is likely that the answer is no, for a larger demo, we would look to alter these two styles. Instead, we can add a simple directive at line 48, thus:

When the code is recompiled, the errors are removed:

Purists may say this is cheating. It's true, our code is still technically not all BEM. In defense though, it's up to each developer to make that decision; there may be elements that have to remain as standard CSS, which we can't convert. In this case, it may be sensible to import these styles using the PostCSS import plugin—we will explore using this more in Chapter 10, Building a Custom Preprocessor.

It's worth noting that the postcss-bem-linter plugin will not display the results of any errors by itself—for this, we need to use a plugin such as postcss-reporter (available at https://github.com/postcss/postcss-reporter, for command line), or postcss-browser-reporter (from https://github.com/postcss/postcss-browser-reporter, displays content in the browser window). Both have a number of options that are worth investigating to help fine-tune what is displayed when the code is processed through PostCSS.

Over the next few pages, we're going to use a relatively recent technique as the basis for our demo—parallax scrolling. Just in case you've been under a rock, parallax scrolling is a single page application, which allows us to scroll through content whilst showing a number of fixed images behind our content:

We'll be using a demo created by Nick Salloum, which is available at http://callmenick.com/_development/simple-parallax-effect/ (I've simplified some of the CSS styles used, removed vendor prefixes, and reduced the number of separate files called by the example). We'll start with a plain CSS version of our demo—go ahead and extract a copy of Tutorial11 to our project area. Try running index.html; if all is well, we should see something akin to the screenshot at the head of this section.

It's a great effect when used well, our interest is in the last section of the CSS file, from around line 133; this section contains the media queries we will convert in our next demo.

If media queries are used correctly, this can open up a world of possibilities; we can tweak our style sheet for anything from an iPhone through to a printer. In our demo, we've used a couple to adjust how content is displayed on sites where displays are larger than 600px or 960px width; altering these to work in PostCSS is a cinch.

We only need to make a couple of changes in the style sheet to switch to using PostCSS, so let's make a start:

Let's make a start on the changes:

It's worth noting that in our demo, we used a typical format of media query: we could for example extend or alter our style sheet to work on handheld devices such as Galaxy tablets; the same principles apply, but clearly different width values will need to be used! For details on the values to use, take a look at http://cssmediaqueries.com, which has a useful list of queries to use for recent devices.

If we want to push the boundaries of what is possible, there are a couple of options that we can consider:

This is one of four pseudo-selector extensions we can use with this plugin, it's a perfect way to style items such as navigation entries, or if we wanted a numbered list of items with different styles for even or odd numbers.

Let's change tack now, and focus on our content. So far, we've concentrated on the page layout, but we can take it further by making images truly responsive; let's dive in and take a look.

Adding responsive capabilities to a site using PostCSS is simple; it will depend largely on your requirements as to how we make the images responsive, but the two key plugins to look out for are postcss-responsive-images (available at https://github.com/azat-io/postcss-responsive-images), and postcss-at2x (available at https://github.com/simonsmith/postcss-at2x).

We will cover the use of the postcss-at2x plugin in a moment, but for now, let's take a look at using the postcss-re sponsive-images plugin.

Making our images responsive requires a single line of code to be added to any image-based rule; let's dive in and add this capability to a copy of the Tutorial13 folder from the code download that accompanies this book:

Although it's easy enough to install and use this plugin, it works best when referencing images directly in our HTML code, and not through the use of background: or content: url(…) attributes in our CSS.

What does this mean for us? It's a little limiting, as the purists amongst us may prefer to hive off asset attributes to CSS style sheets such is open source software, though this is one limitation that is bound to be fixed in the fullness of time!

The keen-eyed amongst you will spot that the image presentation clearly needs further work—for example, the paper clip isn't repositioning when the window is resized, and we need to set a minimum width so that there is some white space around the image when we resize it:

The key principles remain the same though, irrespective of the presentation, removing the fixed image sizes and replacing with a max-width of 100% is a good step to making an image responsive.

To get a true responsive image though, we ideally would use the new HTML5 <picture> tags—trouble is, PostCSS doesn't yet have a plugin to implement these tags!

In the absence of any available capability to handle the use of <picture> tags within PostCSS, we can instead take a more traditional route and use media queries to help switch between different images, depending on the available screen estate.

We can go a step further, and even switch in images of better resolution if the device supports it—I'm thinking of course of Apple iPads or iPhones, which support retina images. We can easily use this format when working with PostCSS; for this, we need to make use of the postcss-at2x plugin by Simon Smith, available at https://github.com/simonsmith/postcss-at2x. I feel a couple of demos coming on, so without further ado, let's go explore using this plugin.

Retina images, a term coined by Apple's marketing team, contain up to twice as many pixels in the same space as standard images. This allow us to switch in images of higher quality (or resolution) automatically, provided we're using a device that supports their use.

This might be as simple as an iPhone, or something more substantial like an iPad—Apple's marketing clout means that they are probably two of the most popular portable devices that people own! But I digress…

At a technical level, we have two routes available for adding retina images, before we explore these in more detail, let's just remind ourselves of the basics:

@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi) { 
  #retina img {
    content: url("../img/mothorchid@2x.png");
  } 
}

This code is an extract from the CSS style sheet in the Tutorial15 folder, which is available in the code download that accompanies this book; try previewing index.html in a browser.

The image displayed displays the text 8-bit version—to switch, try this:

We can then switch between different devices using the dropdown—try switching to Apple iPad; you may need to press F5 to refresh the display. If all is well, it will switch between 8-bit and 24-bit versions of the orchid image.

This is all good, but we're clearly not using PostCSS here—what are our options? Well, we have two that we can use: customMedia() or the postcss-at2x plugin. We've already covered the basics of using customMedia in the Exploring custom media queries in PostCSS section; for this, we would use a variable such as this:

/* media query for hi-resolution image support */
@custom-media --hi-resolution screen and (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi);

This would be coupled with a query such as this:

@media (--hi-resolution) { 
  #retina img {
    content: url("../img/mothorchid@2x.png");
  } 
}

When compiled, and run in Google Chrome (to take advantage of its responsive design tools), we can see the image switch from 8-bit:

…to a 24-bit version of the image:

A peek at the active style rules view shows the media query update automatically:

This is good, but still a manual approach that takes time—instead, we can use a quicker route to achieve similar results. The alternative route, using postcss-at2x, is a simpler option—instead of working out what resolution ratio to use, we simply add the term at-2x to our style rule:

#retina img { background: url("../img/mothorchid.png") at-2x; }

This automatically compiles to produce the relative resolution statements for us in our style sheet. It's a useful trick to use when working with iPads and other devices that can support hi-res images.

Let's dive in and take a look at this in more detail.

The great thing about this plugin is that it deals with creating the media query for us; all we need to do is add the at2x tag to any image where we want to display hi-resolution versions in the browser. There is always a risk that we may end up producing queries that are not 100% optimized (for example, combining identical breakpoints into one block, and so on); we will explore a couple of options to help keep our queries working efficiently towards the end of this chapter.

As an aside, a more concise option for working with hi-res images which is frequently forgotten, is the use of image-set(); this performs in a similar fashion, by providing different versions for devices that support high-resolution images. PostCSS provides a fallback option in the form of postcss-image-set (available from https://github.com/alex499/postcss-image-set), which sets a basic image that will work in those browsers that don't support the use of image- set() within a style sheet.

So, we've covered a number of key topics around making content responsive, using media queries; what does this mean when using PostCSS? The simple answer is that it opens up a world of possibilities—if your site needs to use media queries, then it is very likely that we can use PostCSS to compile our queries into valid CSS rules. To pique your interest, here are a couple of options to consider:

Okay, we've covered making images responsive using PostCSS, but what about text? Pages won't look good if text doesn't flow properly when content is resized. Thankfully we can apply similar principles to text, using the postcss-responsive-type plugin by Sean King—let's take a look at it in action.

How many times have you bought something from an e-commerce site? If you've bought as much as I have online, then no doubt you will have seen shopping carts with assorted payment card icons. These may be small, but they are nevertheless key to our site—after all, how can we tell if using a particular credit card might fail, if the online retailer doesn't accept Mastercard, for example? Seems obvious, but it's not always easy to tell.

Leaving that aside, it is a cinch to create an image sprite with PostCSS; gone is the dependency on SASS: in its place we can use the postcss-sprites plugin (available from https://github.com/2createStudio/postcss-sprites) to produce our composite image. Let's dive in and take a look.

For this demo, we will use the credit card icons available at http://findicons.com/pack/2102/credit_card_debit_card; please feel free to substitute if you would like to use different icons.

All of the code for this tutorial can be found in the Tutorial21B folder, in the code download—we will start afresh by installing the postcss-sprites plugin:

At this stage, we can then copy the code to our website, along with image—instead of using four separate icons (which each require separate calls to the server), we can cache the single icon. This will result in faster response times with fewer calls to our server. The compiled style sheet can be found in the dest folder, with the composite image one level up, in the img folder:

Even though this is a simple process, it's worth noting a key point with how our gulp file has been configured—the use of a configuration object for the sprites plugin:

var opts = {
  stylesheetPath: 'dest/',
  spritePath    : 'img/sprite.png',
  path          : 'src/img/'
};

It's not a process we've used to date, but it does not mean that it is any less useful—it simply boils down to a matter of personal preference and readability. It does make it easier to read the calls for each plugin we assign; in this instance, we're only using one, but you can imagine what it will be like with multiple plugins in use:

gulp.task('autoprefixer', function() {
  return gulp.src('src/*.css')
    .pipe(postcss([ sprites(opts) ]))
    .pipe(gulp.dest('dest/'));
});

Okay, let's change tack and take a look at a different side to using images with PostCSS: using SVG format images. Standard images don't always scale well, particularly when used in a responsive environment; sometimes we might use retina images instead, but an alternative to consider is the use of SVG images.

We'll use the postcss-svg plugin (from https://github.com/Pavliko/postcss-svg), to manipulate some icons from the Evil Icon package (available from https://github.com/outpunk/gulp-evil-icons), as part of the next demo:

Although this is a simple demo, we've covered some useful tips and tricks within; it's worth taking some time to explore how the demo was put together in more detail.

There are several key elements to this exercise that are worthy of attention, the use of a CDN link and Node to provide the style sheet and icons for Evil Icons, the compiled HTML file and the references to use within our custom style sheet. We will cover all of these, but first let's explore the gulp file in more detail.

We begin with these two lines:

var evilIcons = require("gulp-evil-icons");
var postcssSVG = require('postcss-svg')

You should not be surprised to see the latter, but the former is present as the Evil Icons library can be installed using the gulp-evil-icons package. There are a number of different options available for installing, but as we're already using Gulp, it makes sense to continue using the task runner.

Next, we spread our work over two tasks—the first compiles the HTML code to assign the relevant icon image to our <icon> statements within our markup:

gulp.task('icons', function () {
  return gulp.src('src/index.html')
.pipe(evilIcons())
    .pipe(gulp.dest('dest/'));
});

To change the colors requires the use of the postcss-svg plugin, here referenced by postcssSVG:

gulp.task('changecolor', ['icons'], function() {
  gulp.src('src/style.css')
  .pipe(postcss([ postcssSVG() ]))
    .pipe(gulp.dest('dest/'));
});

We of course had to update our default task, if we simply call gulp at the command line, then it will know to run all of these tasks in turn:

gulp.task('default', ['icons', 'changecolor', 'lint-styles' , 'rename', 'sourcemap' ]);

The last step also applies a similar update to our watch facility:

var watcher = gulp.watch('src/*.*', ['default', 'icons', 'changecolor', 'lint-styles', 'rename', 'sourcemap']);

If we then take a look within the HTML markup, we can see a link to the Evil Icons library that was installed using Node.js:

<link rel="stylesheet" href="../node_modules/gulp-evil-icons/node_modules/evil-icons/assets/evil-icons.css">

We then put our customizations into a separate style sheet:

<link rel="stylesheet" type="text/css" href="css/style.css">

These look something like this:

At this stage, the CSS styles may look simple, but the HTML markup is anything but; the postcss-svg plugin has added an in-line version of our icons to the HTML markup, with the appropriate edits made from our custom style sheet:

Sometimes, it is easy to wonder if using SVG is worth the extra markup, the main benefit being that if it is added in-line, then we reduce the number of calls to external resources; any content that requires altering can be done, without sacrificing the quality of our images.

We concentrated on using the postcss-svg plugin throughout our exercise, as a start to manipulating SVG images within the PostCSS system; there are some more options available, which may be of interest:

If you have a need to provide a fall-back position for SVG files, then you can try the postcss-svg-fallback plugin, available from https://github.com/justim/postcss-svg-fallback— we will use this plugin later, in Chapter 8, Creating PostCSS Plugins.

Okay, let's change tack: using SVG images can be a little heavy handed if all we need is a straightforward format for displaying images, right? Well, we could use standard formats, or one which has superior quality while maintaining smaller sizes. I'm talking about the lesser-known WebP format from Google—let's dig in and find out more about this format, and why it deserves more attention.

Image switching is nothing new, we covered one aspect back in Chapter 4, Building Media Queries, when we used PostCSS to switch-in hi-res images when supported in the browser.

We can use a similar technique, but this time with image formats, Google's WebP format was designed as a replacement for the myriad of other image formats available for the web. In an ideal world, we would use the new <picture> tag to take care of switching images automatically:

<picture>
  <source srcset="../img/landscape.webp" type="image/webp">
  <img src="../img/landscape.jpg" alt="The Oslo Opera House">
</picture>

It's not supported in all browsers, so instead, we can use a mix of PostCSS and Modernizr to apply the same effect. The plugin we need for this task is the webpcss plugin (available from https://github.com/lexich/webpcss)—we will need to run npm install gulp-webp --save-dev in a Node.js command prompt session to install the plugin. Let's dive in and take a look at it in more detail.

Before we get stuck into using PostCSS, let's take a moment to perform a quick test. The files for this tutorial are in the Tutorial 23 folder:

In both cases, the image sizes reduced significantly, the JPEG version dropped from around 12.5 MB to just over 7 MB; the PNG format shrunk from an enormous 25 MB to around the same size!

Okay, time for another demo! Let's now make use of PostCSS to create our styles for both standard JPEG format, and WebP equivalents:

For this demo, we'll use the gulp-webpcss plugin, available from https://github.com/lexich/webpcss:

If we run the same index.html in Google Chrome or Firefox, at first we should not see any difference—we'll only see the difference when viewing the compiled source within the Developer Toolbar in Chrome:

The real benefit, though, is in the img folder within our project area, the original JPEG image we use is 222 KB; however, the WebP is a fraction of this size: it weighs in at just 82 KB. See what I mean about the saving in space?

Okay, onwards we go: time to focus on another area of site building, which is manipulating colors. Colors play a key role within any site, as they make up a part of the message to the end user; let's dive in and take a look at some of the options available when using PostCSS.

In this exercise, we're going to take a look at mixing colors; postcss-color-palette allows us to choose multiple colors by name (and not by number!), then converts them to HEX equivalent values. We can then either create gradient-type effects, or simply mix the colors together (using postcss-color-mix) to produce a new color.

Let's make a start:

Okay, the colors I've chosen clearly aren't going to win any style awards any time soon, but they help serve a purpose: it is very easy to use proper color names, if preferred, while still allowing PostCSS to compile them into valid HEX values. That aside, let's take a moment to consider the code we've used in this demo—it does raise a few key points, which we should cover, when using these plugins.

The demo we've created follows similar principles to most other demos we've built so far; we begin with declaring variables to store instances of our plugins, thus:

var palette = require('postcss-color-palette');
var colormix = require('postcss-color-mix')

The magic then happens in this task, within our gulp file:

gulp.task('palette', function () {
  return gulp.src('src/*.css')
  .pipe(postcss([ autoprefixer, palette({ palette: 'mrmrs' }), colormix() ]))
  .pipe(gulp.dest('dest/'));
});

Notice that we've specified a palette to use, the mrmrs option is the default, but we can equally use material or flatui as alternatives. All three reference the webcolors plugin from https://github.com/zaim/webcolors/; this package could be expanded to include other palettes if desired.

With the links to our two plugins in place, and the task set up, we can then begin to specify rules within our style sheet, which will use the plugins. We've created three, and all three use the postcss-color-palette to determine what the HEX value should be for each color; the third and final mixes the two colors together once HEX values have been assigned:

#box0 { background: linear-gradient(aqua, blue 50%, purple); }

#box1 { background: linear-gradient(to right, orange, red, yellow); }

#box2 { background: mix(teal, navy, 80%); }

Getting the mix of the color right for the third rule isn't easy, the key to a successful mix is to avoid using colors that are in the same spectrum; the closer they are, the less impact the mix will have!

If you want a quick way to gauge how well colors have mixed, then try http://jackiebalzer.com/color—this demo has a mix() option in it, which will compile them in the browser and avoid the need to run the compilation process manually.

We've covered some of the plugins that are likely to be more popular; there are more available via the PostCSS.parts directory, which may be of interest:

In the meantime, let's move on: we've explored using palettes to select our colors, before mixing them to create new ones. This is just scratching the surface of what is possible; how about creating different shades of colors, using functions such as darken(), tint() or lightness()? Such functions already exist in most preprocessors, such as SASS; let's explore how we can achieve the same results using PostCSS plugins.

A useful facility within most CSS preprocessors is the ability to create new colors dynamically, we can do this either by adjusting a color channel, or applying a filter effect to the color, such as making it darker:

The benefit of this is simple, it allows us to reduce the number of base colors we assign by default; the remaining colors can be created automatically. If we need to change one of our base colors, then any colors created dynamically should still work.

Thankfully, we can achieve the same effects within PostCSS, to do this, we need to make use of the postcss-color-function plugin, available from https://github.com/postcss/postcss-color-function. We'll also be using the css-color-converter plugin, to help manage conversion between different color formats.

Let's explore this in more detail with a simple demo:

Try previewing the results within a browser, if the compilation was successful, we should see four boxes with different shades of red appear, as shown at the start of this exercise. The question is though, we've seen the results appear, but how does PostCSS know to create these colors?

It's a good question, the conversion process is very simple; the trick to it, though, lies not within compiling, but working out how to achieve the color! Odd as it may seem, choosing the color isn't as easy as it looks; let me explain more:

The compilation process is, like other PostCSS plugins, very easy to configure—we begin of course with creating a variable that defines the color-function plugin:

var colorfunction = require('postcss-color-function');

Next up, we add a reference to our principal gulp task, here we've used both autoprefixer and the color-function plugin together, but the former isn't strictly needed, as we're not adding any vendor prefixes:

gulp.task('autoprefixer', function() {
  return gulp.src('src/*.css')
    .pipe(postcss([  autoprefixer, colorfunction() ]))
    .pipe(gulp.dest('dest/'));
});

The real magic, though, is in the colors we assign within our style sheet—our first box is a control, with a standard red color:

#box0 { background-color: #ff0000; }

Next up, we're adding a tint of 60% to box1, which has the effect of turning it a light pink:

#box1 { background-color: color(red tint(60%)); }

Box2 goes the other way, even though we've used a lightness filter (where you might expect a similar result as box1), the negative number makes it a brown-red color:

#box2 { background-color: color(red lightness(-20%)); }

The final box, box3, continues the brown theme from box2, but makes it lighter. Note though, that in the comment, this shade is what would be produced if we had applied a sepia tone:

#box3 { background-color: sepia(red, 0.7);}

The question is, how would we know that this is indeed a sepia filter being applied?

At face value, it looks like we've selected red, then altered each channel by a specific amount to get the final result.

A drawback of using this plugin is that it doesn't have functions to support all of the equivalent CSS3 filters available today; it does mean we have to be resourceful, and calculate what the color should be directly. We will be able to change that in the next demo—there will be occasions when we need to create our own custom filters; a good example is sepia. It does mean more work upfront, but it allows us to then call a sepia() function by name, rather than approximate the final result.

If you struggle to find what a color should be once a filter is applied, take a look at http://jackiebalzer.com/color; this is a great site that allows us to choose a color and see what the results are when filters are applied. It is written for SASS, but the end result will be identical for PostCSS. A site such as ColorHexa.com (http://www.colorhexa.com) is a good help too, we can use it to verify what color values should be when a filter has been applied.

On we go. We discovered during our exercise that the postcss-color-function plugin doesn't cover all of the CSS3 filters that we can use in CSS; for the sepia example, we had to assign a calculated color value, rather than applying a filter effect. Let's fix that now. With a bit of upfront rework to our demo, we can create our own custom functions. It means that if, for example, we want a sepia effect, then we can call sepia(), rather than calculate what the final color should be!

In our previous demo, we took a look at programmatically changing colors—this is a function that has been present in most CSS processors (such as SASS or Less) for some time.

There may be occasions where we require a finer degree of control over changing colors, and that simply using existing functions provided by the postcss-color-function plugin isn't sufficient, or that the desired filter isn't available. If we're feeling inclined, we can create our own color functions; for this, we can use the postcss-functions plugin, available from https://github.com/andyjansson/postcss-functions, to expose the use of JavaScript functions in our task file.

It's worth noting, though, that if a CSS3 filter doesn't exist, then most can be created using a combination of different calculations (such as the sepia example from the previous demo). This may technically work okay, but it is easier to simply reference a sepia filter by name, rather than work out that #box3 has a sepia effect applied!

I feel a demo coming on, so without further ado, here's a screenshot of what we're going to create:

In short, we're using a standard shade of red (#ff0000, just to be clear!), and calculating various shades using a tint, darken, or sepia filter.

Let's take a look at how to create these colors in more detail:

If we take a look at the contents of the gulp task file in more detail, it will look larger than previous exercises; it might look like we're doing more, but in reality, a lot of it we've already seen before, in earlier demos. Let's take a look at it in more detail.

function darkenColor (value, frac) {
  var darken = 1 - parseFloat(frac);
  var rgba = color(value).toRgbaArray();
  var r = rgba[0] * darken;
  var g = rgba[1] * darken;
  var b = rgba[2] * darken;
  return color([r,g,b]).toHexString();
}

gulp.task('autoprefixer', function() {
  return gulp.src('src/*.css')
  .pipe(postcss([  autoprefixer, functions({
    functions: {
      tint: tintColor,
      darken: darkenColor,
      sepia: sepiaColor
    }
  })
  ]))
  .pipe(gulp.dest('dest/'));
});

Creating filters with PostCSS shouldn't be all boring though, we can absolutely have some fun with filters! A quick and easy way to apply some additional style to an image is through the use of Instagram filters—thankfully there is a pre-built plugin we can use for this purpose.

Enter the Instagram plugin, available from https://github.com/azat-io/postcss-instagram. Let's get stuck in and create a simple demo:

At this point, if we try to preview the results in a browser, we should see something akin to this screenshot:

The key to this is in the main CSS style sheet, we can apply the required filter using nothing more than this within the rule:

This applies the 1977 filter (one of the filters available with the plugin). If we take a look at the compiled code, we can see that the plugin has added some additional rules; one to take care of creating the filter, and two to take care of positioning the filter on top of the image.

If we take a look at the compiled code, we can see the changes made by the plugin:

If you really want to get into the depths, then it's worth taking a look at the source code for this plugin, at https://github.com/azat-io/postcss-instagram/blob/master/index.js. It is fairly complex, but if you look carefully, you can see signs of the filter code that is used to apply the effect to our images.

At this point, be surprised to hear that, our first tip is not directly related to SASS or even Bourbon Neat, but to the color scheme!

"Why", I hear you ask, "are we talking about the color scheme first?" There is a good reason for this: we've used variables to reference our colors, but could equally have used SASS functions to create the values. We've already covered this back in Chapter 5, Managing Colors, Images and Fonts, where we covered the use of the postcss-color-function plugin to build these values; we will use it again later in this chapter.

The real tip here, though, is using a nifty applet by Lokesh Dhakar, called Color Thief (hosted at http://lokeshdhakar.com/projects/color-thief/). We can simply drag and drop our header image in and get a full swatch of suitable colors:

The only downside is that it doesn't provide the color values; we can get these from the page's source instead.

The key to our demo is at lines 33, 63 and 69-these are Bourbon Neat mixins that control the format of the outer container (line 33):

They also control the format of each of the two content areas within (lines 63 and 69):

When compiled, the outer-container mixin adds a max-width of 72% to the .wrapper class controlling the main section, while the span-columns() mixins add float, display, width, and margin-right attributes to each element, like this:

In addition to the outer-container() and span-columns() mixins, the demo uses percentage values as much as possible, where rem or pixel values have been specified, then maintaining a cohesive design when resizing these elements is less critical.

We will, however, make some improvements later in this chapter, when we improve the responsive capabilities of our demo. For now, let's continue with our transition, and introduce the use of PostCSS plugins into our process.

Our gulp file, as it stands, is perfectly usable, but isn't really as useful as it could be—there are a handful of tasks we've built into previous exercises, but which of these are missing here.

A perfect example is the addition of source maps, but how about minifying our code too? Let's take a moment to refine our task list, and add in the missing tasks:

We now have a working gulp file, that includes all of the configuration tasks required for our exercise—let's put it to the test by compiling some example code, to confirm it all works as expected.

A key part of our process is testing our gulp file to ensure it works; not only should it run all of the required tasks, but in the correct order, and produce the expected results. Although we've reused existing code for our gulp file, we've made some major changes to our gulp file—let's take a moment to test it is working, using the code from our previous demo.

To get our demo working under PostCSS, we need to make some changes to our code:

The demo that we've constructed is nearly identical to the original version. This proves that we have a working capability, which we can use to build our sites. The changes we made to our code are very simple, we added a @neat-outer-container to define how wide our site should be, followed by multiple instances of @neat-span-columns, to define how many columns each element should span.

Let's put some of this new knowledge to constructing something a little more useful, in the form of an example site with content. We'll reuse the example site page we created earlier in the chapter, and work through converting it for use with PostCSS plugins.

Making the switch requires changes in both the gulp task file and style sheet. These are not to change how the page will look, but to maintain the same theme from the original demo. The key changes made to the style sheet are:

In addition to altering our style sheet, we also had to make some changes to the gulp task file. They center around replacing the main compilation task and adding in additional tasks to manage production and minification of our source files:

At this stage, do we have a working demo ready for use? Well, not quite, but let's try resizing our demo:

Hmm, what's happened to our content? It doesn't look great, does it? We can easily fix it though; it just requires the addition of some media queries to reorganize how our content is displayed on the screen. Let's dive in and take a look at what is needed to get our demo looking better at smaller sizes.

Getting our design to work properly for smaller devices such as iPhones is easy when working with PostCSS: we can use the postcss-media-minmax plugin available from https://github.com/postcss/postcss-media-minmax.

"How can PostCSS help us though?", I hear you ask. Easy, the point at which most people trip up when working with media queries is in setting the breakpoints, or determining where our designs break at specific sizes. The postcss-media-minmax plugin helps to make the text a little more human; after all, if a design works when the size is greater than or equal to an amount, why not say that in our code?

To see what I mean, let's get stuck into fixing our code. For simplicity, we will focus entirely on resizing our content for an iPhone 6, using 375px by 627px as our breakpoint (as determined by using Google Chrome's Responsive Design view). We will continue exactly where we left off from the previous demo:

If all is well, we should see something akin to the following screenshot, when enabling Chrome's Responsive Design view, and switching the Device setting to Apple iPhone 6:

The changes we've made to our code are simple, and limited to supporting iPhones. This is just the tip of the iceberg, though: there is so much more we can do!

For example, instead of specifying an exact width value as our min-width attribute (or for the width of #beta, for that matter), we could consider using @neat-span-columns to provide this value for us. Of course, we can't limit ourselves to one media query, we need to ensure we have enough media queries to cater for the devices we need to support.

This does not mean that we need to have a 1:1 relationship between a query and a device. Provided we design our queries carefully, we can set existing ones to cover several devices. Ultimately, though, the principle is still the same, but instead of using the standard colon notation, we can use the easier to read >= or <= symbols to define the breakpoint range when working with queries using PostCSS.

In an ideal world, any project we build will have as few dependencies as possible; this applies equally to JavaScript or jQuery-based content as it does to CSS styling.

To help with reducing dependencies, we can use libraries such as TransitJS or Velocity to construct our animations. The key here is to make use of the animations that these libraries create, as a basis for applying styles we can then manipulate using .addClass() or .removeClass(). To see what I mean, let's explore this concept with a simple demo:

Save the file, then try previewing the results in a browser—if all is well, we should see no material change in the demo:

However, the animation will be significantly smoother—the frame count is higher, at 44.28FPS, with fewer dips:

Let's compare this with the same profile screenshot taken for the Revisiting basic animations section, earlier in this chapter—notice anything?

Profiling browser activity can be complex, but there are only two things we need to concern ourselves with here: the FPS value and the state of the green line. The FPS value, or Frames Per Second, is over three times higher, and for a large part, the green line is more consistent, with fewer, more short-lived dips.

This means that we have a smoother, more consistent performance; at approximately 44FPS, the average frame rate is significantly better than using standard jQuery—but we're still using jQuery!

There is a difference, though—libraries such as Transit or Velocity convert animations, where possible, to CSS3 equivalents—if we take a peek under the covers, we can see this in the flesh:

We can use this to our advantage, by removing the need to use .animate() and simply use .addClass() or .removeClass()—we'll see this in action later in this chapter, in the Switching classes using jQuery section.

To take it to the next step, we can use the Velocity library to create a version of our demo using plain JavaScript—we'll see how as part of the next demo. Beware though—this isn't an excuse to still use JavaScript; as we'll see, there is little difference in the frame count!

Many developers are used to working with jQuery—after all, it makes it a cinch to reference just about any element on a page! Sometimes though, it is preferable to work in native JavaScript; this could be for speed. If we only need to support newer browsers (such as IE11 or Edge, and recent versions of Chrome or Firefox), then adding jQuery as a dependency isn't always necessary.

The beauty about libraries such as Transit (or Velocity) means that we don't always have to use jQuery to still achieve the same effect; as we'll see shortly, removing jQuery can help improve matters! Let's put this to the test, and adapt our earlier demo to work without using jQuery:

With jQuery as a dependency no longer in the picture, we can clearly see that the frame rate has improved; the downside, though, is that support is reduced for some browsers, such as IE8 or 9. This may not be an issue for your site—both Microsoft and the jQuery Core Team have announced changes to drop support for IE8 - 10 and IE8 respectively, which will help encourage users to upgrade to newer browsers.

It has to be said though, that while using CSS3 is preferable for speed and keeping our pages as lightweight as possible, using Velocity does provide a raft of extra opportunities that may be of use to your projects. The key here, though, is to carefully consider if you really do need them, or whether CSS3 will suffice, and allow you to use PostCSS.

At this point, there is one question that comes to mind: what about using class-based animation? By this, I mean dropping any dependency on external animation libraries, and switching to using plain jQuery with either .addClass() or .removeClass() methods.

In theory, it sounds like a great idea—we can remove the need to use .animate(), and simply swap classes as needed, right? Well, it's an improvement, but it is still lower than using a combination of pure JavaScript and switching classes. It all boils down to a trade-off between using the ease of jQuery to reference elements, against pure JavaScript for speed:

The real change in our code, though, will be apparent if we take a peek under the covers using a DOM Inspector:

Instead of using .animate(), we are using CSS3 animation styles to move our square-small <div>. Most browsers will accept the use of transition and transform, but it is worth running our code through a process such as Autocomplete, to ensure we apply the right vendor prefixes to our code.

The beauty of using CSS3 here is that, while it might not suit large, complex animations, we can at least begin to incorporate the use of external stylesheets such as Animate.css, or even use a preprocessor such as SASS to create our styles.

It's an easy change to make, so without further ado, and as the next step on our journey to using PostCSS, let's take a look at this in more detail.

The effects used in our demo are quite striking—indeed, one might be forgiven for thinking that they required a lot of complex JavaScript!

This, however, could not be further from the truth—the Animate.css file contains a number of @keyframe based animations, similar to this:

@keyframes bounce {
  0%, 20%, 50%, 80%, 100% {transform: translateY(0);}
  40% {transform: translateY(-1.875rem);}
  60% {transform: translateY(-0.9375rem);}
}

We pull in the animations using the usual call to the library, within the <head> section of our code. We can then call any animation by name from within our code:

  <div id="gallery">
    <a href="#"><img class="animated bounce" src="http://lorempixum.com/200/200/city/1" alt="" /></a>
...
  </div>
  </body>

You will notice the addition of the .animated class in our code—this controls the duration and timing of the animation, and is set according to which animation name has been added to the code.

The downside of not using JavaScript (or jQuery for that matter) means that the animation will only run once when the demo is loaded; we can set it to run continuously by adding the .infinite class to the element being animated (this is part of the Animate library). We can fake a click option in CSS, but it is an experimental hack, which is not supported across all browsers—to effect any form of control, we really need to use JavaScript (or even jQuery)!

Okay, onwards we go: we've covered the basic use of pre-built libraries, such as Animate. It's time to step up a gear, and make the transition to PostCSS. As a start, we will use Gulp as our task runner of choice, with SASS. The latter is a perfect choice, as it fits in with the plugin we will use later in this chapter. Let's take a look at what is involved in laying the groundwork for our conversion to PostCSS.

Animating content can be a double-edged sword. Added with care, it can really lift a site to the next level. If it is done badly, then patronage of the site is likely to drop like a stone!

In our last demo, we constructed a simple gallery effect—this was more to show off the different types of animated effects we can add, rather than produce something that would win awards. Over the next few pages, we'll continue with our demo, but this time reconfigure it to use the SASS version of Animate.css. We will also introduce the use of a task runner to compile our code—as this is a requirement for using PostCSS, it seems a perfect point to start using it, as the final part of our transition to working with animation and PostCSS.

Without further ado, let's add the changes to our previous demo:

Our demo has now been converted to using Animate.scss—we could easily have chosen to use any one of several compilers (such as Koala—http://www.koala-app.com), but instead chose to use Gulp. It acts as a perfect route into making the transition to using PostCSS—as we've seen in earlier demos, we've already used a task runner in the form of Gulp for this purpose. This allows us to make that gradual transition—when all of the SASS elements have been converted, we simply drop the task from within our gulp file to complete the transition.

So, what next? We've created a basic gulp task file, which we used to compile our SASS code to valid styles.

But this is just a small part of the story; we need to add a lot more to make our compilation process useful and ready for conversion to using PostCSS.

Let's get started:

If we preview the results of our work, we should see no change in functionality within the demo, but can be safe in the knowledge that we now have minified versions of our files available for use—after all, it is always better to use minified files in a production environment!

We've now laid the groundwork for our conversion to using PostCSS—the keen-eyed among you should spot that the plugin reference for PostCSS has already been added to our gulp file, ready for the next stage in our conversion process. Everything is now in place in our gulp file, save for the SASS task – at the appropriate point we will remove the SASS task and replace it with a PostCSS equivalent; this will take place in our next exercise. Before we do so, it's worth taking a little time to explore what is available within the PostCSS ecosystem—although there isn't a great deal on offer, we can still produce usable code for compilation within PostCSS.

Although we may not see any change in the appearance of our demo, there will clearly be a difference in how it behaves. To view this, we need to take a look under the covers of our demo, at the code.

For this demo, we added an animation-name property, and assigned it the name bounce; when compiled, PostCSS adds in the appropriate @keyframes rules to the code:

So, if we were to take a look at the performance, how does it compare? Even with the extra animation property assigned, it still pulls a respectable frame rate of 48.29FPS, when compared to using standard .animate():

This helps reinforce that where possible, we can improve performance by removing any dependency on using .animate() in our code. The use of CSS styling to animate content isn't quite ready to replace JavaScript, but it is slowly getting there!

Okay, onwards we go: we've briefly looked at the various ways to animate content; it's time to make that final transition to using PostCSS. How many times have you seen forms that display the label above, or to the left of, each field? Sure, it gets boring after a while, seeing the same old design! It's easy to change, so there is no excuse for not doing so. To prove this, we're going to use PostCSS to slide each label up when that field has focus. Yes, you heard me right…slide up. Let's take a look at how we can provide a new take on that venerable piece of functionality for any site.

While researching for this book, I came across an issue in the current release (1.0.0), whereby style sheets weren't compiling properly if they had multiple rules within; there are occasions when plugins may or may not work for your environment, and this is one of them!

Thankfully, this is an easy fix—if we take a look within the postcss-transform-shortcut folder within the node_modules folder in our project area, we should see this:

Simply copy the contents of the file at https://raw.githubusercontent.com/pc035860/postcss-transform-shortcut/07af8a78d1fb5e7fdeebc8c7f56c0c9ecdd83efb/index.js and paste straight over the top of index.js; this should resolve the issue.

Now that we have our updated plugin in place, we can get on with building our demo! The next exercise will take the form of a simple credit card form—I don't suggest you use it in a production environment, as it is purely designed to show the animation effects only, and does not have any security attached to the form!

That aside, here's a screenshot of what we're going to produce, using PostCSS:

It's a simple demo, based on a codepen created by Michael Arestad, which you can view at http://codepen.io/MichaelArestad/pen/ohLIa—I've simplified and reworked the demo to illustrate how we can use PostCSS to compile the code into valid CSS styles.

Okay, let's make a start with setting up our demo:

It's a simple demo, but it shows off how we can use animations perfectly—it adds a subtle effect to the label, and doesn't spoil the overall use of our form. The use of the plugin does raise a couple of useful points, so let's take a moment to explore what we've just created in more detail.

The key to a successful plugin in PostCSS is one that follows the 1:1 principle—one plugin for one task. The postcss-transform-shortcut plugin is no exception: it takes the various elements that make up a transition rule, and puts them together in the right order. To see what we mean, take a look at these lines from within our style sheet before it is compiled:

Where's our transform: statement? Well, when using this plugin, it's not needed—instead, we can simply specify the various attributes, thus:

.transform {
  transform: skewX(25deg);
  rotate: 180deg;
  scale: 2 2;
  translate: 10px 10px;
}

The plugin is set to recognize these four attributes and compile them into one single rule, as shown in this code excerpt:

.transform {
  transform: skewX(25deg) rotate3d(180deg,0,1) scale3d(2,2,1) translate3d(10px,10px,0px);
}

Any gaps in the attributes will be automatically filled in with default values from within the plugin. We can even use this plugin as the basis for an equivalent for transitions—we will do this toward the end of the next chapter.

Our new plugin is a perfect example of how we can adapt an existing framework to use different values—there are a few key points we should note when using this plugin:

There are plenty of ways we can extend, modify, or create new plugins—the key to any should be that they are kept simple, limited to one task only, and that where possible, you should use the PostCSS plugin boilerplate as the basis for creating the plugins. The plugin we used in this exercise was created manually—this isn't an issue if you are creating it for your own needs, and don't intend to publish the plugin. In the next chapter, we will explore how easy it is to create something using the boilerplate code—it avoids a lot of issues at a later date!

The crux of any plugin centers around index.js—we start with a reference to PostCSS (as a dependency for our plugin); this is followed by the exports function, which exposes functionality to anyone using the plugin:

var postcss = require('postcss');
 
module.exports = postcss.plugin('myplugin', function(options) {

  return function (css) {
    options = options || {};
         
    // Processing code will be added here
  }
});

Next up, we have package.json—this is used to configure and manage locally installed Node packages; given that PostCSS is based on Node.js, we will see something akin to this for any plugin installed as part of the PostCSS ecosystem:

{
  "name": "PLUGIN_NAME",
  "version": "0.0.0",
  "description": "PostCSS plugin PLUGIN_DESC",
  "keywords": [
    "postcss",
    "css",
    "postcss-plugin"KEYWORDS
  ],

The first section contains some basic details about the plugin name, description, and version. If we look through the package.json file, it's not difficult to spot a number of keywords in capitals—at first glance, one might be mistaken for thinking that it renders as invalid JSON.

There is a reason for this—one of the steps for using this boilerplate plugin is to run a script that will replace these keywords with information; the script will transform this into valid JSON. This is something we will cover in more detail later, in the Creating a transition plugin section. For now, assume that this file will be converted to valid JSON during the build process.

Moving on, we then store the name of the author, the plugin's license, and where we can get the source or file bugs relating to the plugin:

  "author": "AUTHOR_NAME <AUTHOR_EMAIL>",
  "license": "MIT",
  "repository": "GITHUB_NAME/PLUGIN_NAME",
  "bugs": {
    "url": "https://github.com/GITHUB_NAME/PLUGIN_NAME/issues"
},
"homepage": "https://github.com/GITHUB_NAME/PLUGIN_NAME",

This section is the most critical—the dependencies section stores details of any dependencies, when used in production; the devDependencies section takes care of dependencies when working in a development environment:

  "dependencies": {
    "postcss": "^5.0.10"
  },
  "devDependencies": {
    "ava": "^0.7.0",
    "eslint": "^1.10.2"
  },
  "scripts": {
    "test": "ava && eslint *.js"
  }
}

A key guideline given by the PostCSS team is that every plugin should be tested—this should always be a given, to help ensure we are creating something that is solid and not likely to cause issues for our users. A part of the boilerplate code contains a suitable test script for this purpose, so let's take a quick look at it now.

The third element that is key to any plugin is the test—this should be stored in test.js, and will look similar to this:

import postcss from 'postcss';
import test from 'ava';

import plugin from './';

function run(t, input, output, opts = { }) {
  return postcss([ plugin(opts) ]).process(input)
    .then( result => {
      t.same(result.css, output);
      t.same(result.warnings().length, 0);
    });
}

/* Write tests here
test('does something', t => {
  return run(t, 'a{ }', 'a{ }', { });
});
*/

We will cover this part in more detail later in this chapter, in the Testing and submitting a plugin section—for now, let's get stuck in to creating a PostCSS-based plugin. We'll start with a quick look at the API, before diving into creating a plugin that applies a specific font stack based on a chosen font, and adds updated declarations if one of those fonts needs to be imported into our site.

With the framework in place, we can then build up our plugin using the PostCSS API; this contains a number of classes, modules, and methods that we can use. The key function in the API is of course postcss—this is the main entry point for PostCSS and is required for all plugins:

var postcss = require('postcss');

Let's take a quick look through what else is available in the API, beginning with the Vendor module.

This module contains helpers for working with vendor prefixes—we can initiate it using this object:

var vendor = postcss.vendor;

The module contains two methods, as shown in the table:

// prefix extracted = '-webkit-'
var vp = postcss.vendor;
vp.prefix('-webkit-clip-path')

// value extracted = 'tab-size'
var vp = postcss.vendor;
vp.unprefixed('-moz-tab-size')

This module contains helpers to safely split lists of CSS values, whilst preserving parentheses and quotes. We can initiate it using this object:

var list = postcss.list;

The module contains two methods, as shown in the table:

// expected result:
// ['1px', 'calc(10% + 1px)']
var ls = postcss.list;
ls.space('1px calc(10% + 1px)')

// Expected result:
// ['black', 'linear-gradient(white, black)']
var ls = postcss.list;
ls.comma('black, linear-gradient(white, black)')

Once the PostCSS object has been defined as a dependency in our plugin, we can begin to manipulate its contents—for this purpose, there are a number of classes available to assist, as shown in this table:

Of course, we cannot manipulate content from within a PostCSS plugin without having access to each CSS node—the API contains a group of useful nodes to help with parsing and manipulating content:

var root = postcss.parse('a{color: darkred}');
root.type         //=> 'root'
root.nodes.length //=> 1

var root = postcss.parse('h1{}');
var rule = root.first;
rule.type       //=> 'rule'
rule.toString() //=> 'h1{}'

var root = postcss.parse('a{color: darkred}');
var decl = root.first.first;
decl.type       //=> 'decl'
decl.toString() //=> 'color: darkred'

var root = postcss.parse('a { color: /* inner */ darkred; /* outer */ }');
var decl    = root.first.first;
var comment = root.first.last;

comment.type //=> 'comment'
decl.between //=> ': /* inner */'

A key role of a plugin is to navigate through each node to help determine if it should perform some action; the API contains a number of methods to assist with parsing nodes:

The main site contains details and examples of all of the methods and classes available within the API—it is worth taking time to familiarize yourself with the options available.

Okay, enough with theory: on we go! Let's change tack and put some of what we've just learnt to good use by constructing a couple of plugins for PostCSS. These will use a real mix of the API commands that we've briefly looked at earlier in this chapter; our first demo centers around a shorthand plugin for creating transition statements within CSS rules in a style sheet, so let's get stuck in and see how it works.

The sharp-eyed amongst you will notice though that if we don't specify one of the four values for our transition plugin, then the code at present won't use the default; hopefully an update will come in a future version of the plugin.

This aside, the process for testing our plugin uses the AVA test runner, available from https://github.com/sindresorhus/ava. The framework for the test is already created within the plugin boilerplate, which leaves us to add the test code to test.js file. Let's take a peek at what's required:

All good so far, right—at this point, we're OK to create a simple demo to prove plugin works…or are we? Well, the test shows a pass, so the code should be OK. But further down there are a ton of errors displayed, similar to this screenshot—what gives?

The test has passed, yet the tests would seem to indicate otherwise; a look further down reveals yet more errors:

This raises some important points about testing, so let's cover these before continuing with our demo.

The main error, or Exported linebreaks to be 'LF'…, is a simple one to fix—it's being caused by Sublime Text being set to use Windows as the default line endings setting. Assuming we're using Sublime Text, let's go ahead and deal with that error:

If we re-run the test, we should see a significant drop in listed errors—there will be some left for us to fix in index.js and test.js, similar to this screenshot:

Most of the errors are self-explanatory—the two that are less obvious are Expected indentation of X spaces… and Line X exceeds the maximum line length…. We can fix the first by replacing all instances of tabs with four individual spaces per tab. The second error is simple to fix—simply split the line of code into two lines.

We need to work through all of the remaining errors, as far as possible—these won't entirely be the same for your version of the plugin, but some will be similar.

Assuming we've cleared most of the errors, we should be left with just one:

Is this an error we should fix, and therefore can clear from the report? The simple answer is that it depends—it highlights an important point about using linting for code, so let's take a moment to cover this in more detail.

The last error shown in the report presents some challenges—the code is valid, yet ESLint flags the error. The reason for this is that it has found an assignment expression within a while statement initializer; it is treated as a possible mistake in the code and may have unintended effects on the code.

In some respects, it can be treated as a warning, and not necessarily as an error. Prior to July 2013 we could have configured our test to ignore this, but changes made to ESLint since that date mean that this error cannot be cleared without reworking the code.

In our instance, the code is valid and will not cause any errors—it leaves us with several options as to what we can do going forward:

For now, we're going to switch off the test for this error—we can do this by editing the .eslintrc file from within our plugin, and set the value in square brackets to 0:

This will work in the short term, but with a view to revisiting the code to design out the ambiguity at some point in the future.

With our plugin in place, let's test it out—for this, we need a couple of files from the code download that accompanies this book; the files are available in the T43 – building a transition shortcut plugin folder:

At this stage, we've run the test for our plugin—we go one step further, and add our plugin to a test runner service such as Travis CI (at https://travis-ci.org). Although this is a mandatory part of the process for creating any PostCSS plugin, there is a fairly steep learning curve, and anyone working on Windows may run into difficulties! If you are a Windows user, you will have to make test.js executable via the command line—this requires prior knowledge of using Git, which is beyond the scope of this book.

For now, we'll skip past the Travis CI part of the process—the plugin is sufficiently straightforward that the local testing with test.js will suffice. Let's change tack—our plugin contains a number of useful concepts in PostCSS, so let's explore how it is put together in more detail.

The inspiration for this plugin is twofold—at the time of writing, PostCSS doesn't have a great number of animation-based plugins, and it borrows the same concept used in the postcss-transform-shortcut plugin.

We start with the ubiquitous call to initialize PostCSS as a dependency for our plugin:

var postcss = require('postcss');

Next up, we initialize postcss.plugin, to expose functionality within our plugin to the ecosystem:

module.exports = postcss.plugin('postcss-transition-shortcut', function (options) {

At present, our plugin doesn't contain any options, so it will be set as blank; if we had had some options set, then these will be stored in the options array:

options = options || {};

A key part of our plugin is to set some default options—we need to have some default values set, if we don't specify one or more values:

var defaults = {
  property: 'all',
  duration: '1s',
  timing: 'ease-in-out',
  delay: '1s'
};

Up next comes the crux of our plugin—it returns the result of this function:

  return function (css) {
     css.walkRules(function (rule) {
       var transitionRule;
       var transitionValues = [];
       var index = -1, node;
       var attributes = /^(property|duration|timing|delay)$/;

We walk through each rule using css.walkRules—it sets up a number of variables and an array; we also set a search string that will be used to find any instance of our transition properties.

If we find a suitable instance of our property, we then clone it, adding the property name transition before it. We then work through each of up to four properties that may be set, joining them together into the final transition declaration:

       while (node = rule.nodes[++index]) {
        if (attributes.test(node.prop)) {
          transitionRule = transitionRule || node.cloneBefore({ prop: 'transition' });
           var transValues = postcss.list.space(node.value);
           transitionValues.push(transValues.join(','));
           node.remove();
           --index;
         }
       }
       transitionRule.value = transitionValues.join(' ');
    });
  };
});

Let's move on. Our first example was a straightforward plugin; although it does need some further development (as indicated in Testing our plugin), it still serves a useful purpose. In our next example, we'll take a different approach: we will use an existing plugin as a basis for our new version. This plugin, unlike the first one, will not see the light of day in GitHub, though—we'll explore the reasons for this, and more, as part of our next exercise.

At first glance, the code for our plugin may look complex, but in reality it is relatively straightforward to follow—let's go through it in sections, beginning with defining instances of the postcss object and a fontstacks_config object we will use in the plugin:

var postcss = require('postcss');
var _ = require('underscore');

// Font stacks from http://www.cssfontstack.com/
var fontstacks_config = {
  'Arial': 'Arial, "Helvetica Neue", Helvetica, sans-serif',
  'Times New Roman': 'TimesNewRoman, "Times New Roman", Times,
  Baskerville, Georgia, serif'
}

Next up, we add a simple helper function—this is used to convert font names into title case; the names listed in fontstacks_config are case sensitive, and will fail if they don't match:

// Credit for this function: http://stackoverflow.com/a/196991
function toTitleCase(str) {
  return str.replace(/\w\S*/g, function(txt){
    return txt.charAt(0).toUpperCase() + txt.substr(1).toLowerCase();
  });
}

This is the start of the plugin—the first two lines are the obligatory initialization to make the plugin available for use, followed by defining an options object. We then use _.extend to extend the predefined values in our chosen font stack with those added to the configuration object when running the plugin:

module.exports = postcss.plugin('customfonts', function (options) {
  return function (css) {

    options = options || {};
    fontstacks_config = _.extend(fontstacks_config, options.fontstacks);

We then walk through each rule and node, working out if they first contain a font declaration, then if they contain a font name that matches one in the predefined font stacks. If there is a match, then the font name is converted to the appropriate font stack and inserted with any additional fonts specified, but which don't match our font stacks:

    css.walkRules(function (rule) {
      rule.walkDecls(function (decl, i) {
        var value = decl.value;
        if (value.indexOf( 'fontstack(' ) !== -1) {
          var fontstack_requested = value.match(/\(([^)]+)\)/)[1].replace(/["']/g, "");
          fontstack_requested = toTitleCase(fontstack_requested);

          var fontstack = fontstacks_config[fontstack_requested];
          var first_font =  value.substr(0, value.indexOf('fontstack('));

          var new_value = first_font + fontstack;
          decl.value = first_font + fontstack;
        }
      });
    });

In the second half of the plugin, we perform a simpler task—we work our way through each rule and declaration, looking for any instances of @font-face in the code. We then define a fontpath variable that removes any quotes from the supplied values, and a format array to manage the different font formats available for use:

    css.walkAtRules('font-face', function(rule) {
      rule.walkDecls('font-path', function(decl) {
        var fontPath = decl.value.replace(/'/g, ''),
        src = '',
        formats = [
          { type: 'woff', ext: '.woff' },
          { type: 'truetype', ext: '.ttf' },
          { type: 'svg', ext: '.svg' }
        ];

We then build up the relevant statement for each font type, before assembling the custom font declaration and inserting it back into the appropriate point in our style sheet:

        formats.forEach(function(format, index, array) {
          if (index === array.length - 1){
            src += 'url("' + fontPath + format.ext + '")
        format(\'' + format.type + '\')';
          } else {
            src += 'url("' + fontPath + format.ext + '")
        format(\'' + format.type + '\'),\n ';
          }
        });

        decl.cloneBefore({ prop: 'src', value: src });
        decl.remove();
      });
    });
  }
});

Our plugin has exposed some key concepts in PostCSS plugin design—the main ones are the use of .WalkDecls and .WalkRu les (or .WalkAtRules). I would strongly recommend familiarizing yourself with the API documentation at https://github.com/postcss/postcss/blob/master/docs/api.md, which outlines all of the commands available within the API, and gives a brief description of their purpose.

Despite creating what should be a useful plugin, it isn't one that I would recommend releasing into the wild. At this point you may think I have completely lost the plot, but as I always say, "there's method in the madness"—there are good reasons for not publishing this plugin, so let's take a moment to explore why it might not be a sensible move to release this plugin in its current format.

Over the last few pages, we've created what should be a useful plugin to manipulate custom fonts—it automatically builds up the right font stack based on pre-defined settings, and will fill in the appropriate @font-face code for us. At this point we should have a plugin that can be released into the wild, for anyone to use…surely?

Well yes, and no—even though this plugin serves a purpose, it is not one that I would recommend making available…at least not yet! There are a few reasons why, which also help to illustrate the benefits of using the boilerplate code we covered earlier in this chapter:

One might ask why we would even consider this route, if it is likely to throw up issues during development—the simple answer is that it helps us understand something of how plugins should be built. If we're building a plugin for personal use only, then there is no need for some of the files or processes that we have to use when releasing plugins for general use.

This plugin, available from https://github.com/jonathantneal/postcss-short, is a wrapper for several plugins available for the PostCSS ecosystem; these include Shorthand Border, Shorthand Color, and Shorthand Size. Installing the plugin is a breeze—it uses the same format as most other PostCSS plugins, and can be installed using this command within our project root area, in a Node.js command prompt session:

npm install postcss-short --save-dev

The great thing about this plugin (and other plugin packs) is that it removes the need to call lots of separate plugins. We must bear in mind though that to make this worthwhile, we need to be calling most of the plugins in some form or other. If we're only calling one or two from postcss-short, then we may prefer to call them individually, and not use the postcss-short plugin.

Leaving aside any concerns about using the plugin, let's take a look at some examples of it in action. The best way to experience it is to use the online editor at http://jonathantneal.github.io/postcss-short/. We can use this to experiment before adding the final result to our style sheet prior to compilation:

In this example (taken from the plugin site), we've used all of the plugins, with the exception of Shorthand Text and Shorthand Data. In our code, we've used the relevant shorthand as specified for the plugin—PostCSS will compile this into valid CSS styles, as outlined within each plugin.

Which plugins we use will of course depend on our requirements—there is every possibility that you will find yourselves using particular plugins more than others. Staying with the theme of shorthand, though, there is one plugin pack that is likely to feature often in your toolkit—Rucksack. No, I don't suggest this is an opportunity to go on holiday (no pun intended), but more an occasion to use what will be a very useful set of plugins within PostCSS.

For this next demo, we're going to break tradition and not install the plugin we're about to use first, before creating our demo. Instead, we'll set up our demo first—we can then ascertain where Rucksack can be used once we've set our baseline solution.

Our demo centers on a simple image slider, which uses pure CSS3 styling to control the animation. This is a screenshot of what we're going to create:

To see the demo in action, go ahead and extract the T45 – converting to use Rucksack folder from a copy of the code download that accompanies this book—save it to our project area. Go ahead and preview the results by running slider.html in a browser, then click on the numbers in the bottom left to move between different images.

With our demo in place, it's time to install Rucksack, and ascertain where we can use it in our demo! Rucksack, like most other PostCSS plugins, can be installed using the same method—we can use NPM:

A note of caution—there are several plugins available for Rucksack: make sure you install the right one! There is a Gulp plugin, but this does not appear to work within PostCSS, even though we are using Gulp as our task runner.

This aside, let's move on. Before we go through the process of converting our slider to use Rucksack, let's take a quick look at using it in action with a simple easing demo.

Any developer who spends time animating content on a website will no doubt have created rules to control how content eases in or out of the page. Striking the right balance between easing content in and out of the page and the site becoming too overladen with effects takes time to get right!

Leaving aside the awful pun in that last comment, this is where Rucksack can help—one of the simpler plugins that forms part of this package is postcss-easings. This plugin, available from https://github.com/postcss/postcss-easings and one that we touched on in Chapter 7, Animating Content, has but one role in life: convert any recognized easing name into a cubic-bezier equivalent value.

Is there any benefit in doing this, I hear you ask? Well, two that come to mind are consistency and a central point of source. Let me explain what I mean.

A central point of source borrows a principle from CSS preprocessors such as SASS or less, where a single value is defined at the top of the file; any instance found elsewhere in the file will be automatically replaced by its value (in this instance, a cubic-bezier easing). This then helps with consistency: we can specify names for any custom easings in the configuration, which will replace any instance found during compilation.

The benefit of this means that we only need to update one central point (that is, point of source), and can avoid mixing different types of easing values in our code—they will be converted to cubic-bezier values at compilation.

Okay, let's move on: time for a demo! Before we get stuck in, let's quickly cover what we're going to construct. Our demo is a simple affair with four squares that we will animate using nothing more than plain HTML and CSS (yes, no JavaScript). We will use a handful of effects, such as easeOutBack, which looks something like this:

Let's get on and construct that demo…

If you're expecting dramatic effects, then I am sorry to disappoint—this exercise has been kept deliberately simple, to show you how easy it is to use Rucksack. We mentioned earlier that the overall result will be four simple squares that we can animate at will—they will look something like this:

The use of this plugin does raise one important question—we will cover this once we've built our demo:

Our demo was never meant to be anything more complicated—the aim was to show off how easy it is to get a consistent effect, provided the configuration object is correctly set up! It does, however, raise an important question concerning our choice of plugins, so let's explore that in more detail.

Dissecting our demo in more detail

This is one example of where simplicity pays in spades; the postcss-easings plugin requires no configuration for standard use, and will only need configuring if the easing we use are not already part of its core library. The ones we picked for this demo are already defined in the plugin—if we open a copy of the compiled style sheet, we should see something akin to this:

The key to configuring this plugin lies in two lines of code, on or around lines 11 and 16:

var rucksack = require('rucksack-css');
  .pipe(postcss([ rucksack() ]))

Much of what is present in the Gulp task file that we used in this demo is code that we've already seen before; it frequently pays to think ahead, so that we can build a gulp file that can be reused for future projects. Once configured, then any style recognized by the plugin will be compiled into valid CSS.

If we had decided to use a custom easing style, then we can easily update the configuration object accordingly:

In case you're wondering about the name given—this effect replicates the motion when punching the air after you've achieved a good result, particularly if it has been a troublesome issue to solve!

Before we move on to our next exercise, we should answer the question that I alluded to earlier: which plugin should we use? But hold on, we're using the postcss-easings plugin, right?

No, I've not completely lost the plot: the postcss-easings plugin is available separately, and is referenced within the Rucksack pack of plugins. The key here, though, is that if we only need to use postcss-easings, then there is no sense in calling in Rucksack's plugins, which will only add an unnecessary burden to our workflow. Instead, we can change line 11 in our gulp task file to the following:

var easings = require('postcss-easings');

And we can change line 16 to the following:

.pipe(postcss([ easings() ]))

As long as the plugin is still installed from earlier, then the code will be compiled as before, but without the extra overhead of the other plugins that form Rucksack.

If we're working with Rucksack, we've seen that the key to successful use is less about configuring it for use in our Gulp file, and more about deciding which plugins to use. To see what we mean by this, take a look at the original stylesheet from Introducing our demo carefully; it should reveal that we can use a number of plugins to improve on existing functionality:

Now that we've covered the elements we want to use, it's time for us to make the changes. Without further ado, let's make a start:

Next, do a search and replace for each of these three styles—replace the full name with the shortcut names given in the @alias block.

At this stage, we have a compiled set of files. To confirm if the demo works, go ahead and copy them to the css folder within the T45 - converting to use Rucksack folder; try previewing the results of our work by running slider.html. If all is well, we should see the same slider effect:

All should be good, we have a working demo and our code has compiled successfully. At this point we can move on to our next task, right…?

Well, it's worth taking a look at our compiled code first: Rucksack has made some additional changes to our code that we may not have expected to see.

For example, Rucksack has provided pixel-based fallback support for the rem units listed throughout our code, along with the HEX fallback support we discussed earlier:

body {
  font-family: "open_sansregular";
  line-height: 25.888px;
  line-height: 1.618rem;
  background-color: #ecf0f1;
  background-color: rgba(236, 240, 241, 1.0);
  color: #44466a;
  color: rgba(68, 68, 618, 1.0);
}

Next, take a look at line 96—remember the font-size: responsive attribute that we added? This is the compiled result:

font-size: calc(12px + 9 * ( (100vw - 420px) / 860));

Throughout the bottom two-thirds, there are a number of media queries that have been added; these were added as part of making our font styles responsive. Further down, at around line 226, we have this block:

-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=0)";
 -webkit-transition: opacity 0.35s;
 transition: opacity 0.35s;

At first glance, you might wonder where this came from, as we didn't specify an ms-filter attribute in our code. Well, this is thanks to Rucksack—it has added opacity support for IE automatically.

The key to this little exploration, though, is that choosing plugins should be an iterative process that will only really finish when the site is no longer needed. For example, we could easily add another step to our workflow that reduces calc() operations to static values (where allowed—the plugin for this is postcss-calc). We should always consider using postcss-remove-prefixes periodically to keep our code up to date; there will come a time when we either don't need to add prefixes, or existing prefixes become redundant.

Leaving aside the changes to our style sheet, there is one more to consider—you will note that the Autoprefixer plugin has been commented out in our code:

This is with good reason—Rucksack has built-in support for autoprefixer, so there is no need to call it twice; ironically, it simply calls the same plugin that is commented out of our code! It's up to us whether we want to call it from within Rucksack, or separately; this will largely depend on what else is being called from with Rucksack, and whether adding autopre fixer will help provide a stronger case for using Rucksack.

For anyone starting out with PostCSS for the first time, then simply specifying cssnano() as one of the processors for PostCSS should be sufficient:

If we take a look at the T45 – converting to use Rucksack demo, our original style sheet file weighs in at 4KB when compiled, but which drops to 3KB after compression. Granted, it's only a small file, but a 25% drop in size is still not an insignificant drop!

The cssnano plugin is not a single plugin, but a wrapper for a number of plugins, which include examples such as these:

Moving on, there are some key points we should be aware of, when using cssnano:

Okay, let's move on: the second half of our double act is the stylelint plugin pack; unlike cssnano, stylelint takes the opposite approach and allows you to enable any rule as needed, from a list of over 100 available rules. Let's dive in and take a look in more detail.