If we take a look back at our gulp file prior to completing the exercise in Fixing our gulp task file, we can see it worked, but it suffered from a major drawback. The compilation process produced an extra source map which was minified by name, but not in reality! This is clearly something we didn't need—the changes made to this task transformed it into what we have now:

var sourceMapLocation = ['dest/*.css', '!dest/*.min.css'];
...
gulp.task('sourcemap', ['rename'], function () {
  return gulp.src(sourceMapLocation)
...
});

This is a much better version—it only produces one source map file, which is not compressed; compression is not needed. That being said, we can still improve on it; it's simply a matter of working through the documentation to really explore what is available, and see if it can help us. As a starter, try this for size.

There may be instances where we need control over the full URL when compiling our code and creating the source map, for example, if we're transferring from a test environment to a production one. In an ideal world, we would use a relative file structure to avoid this issue, but for those occasions where this isn't possible, a simple change to our Gulp task will suffice:

    .pipe(sourcemaps.write('maps/', {
      sourceMappingURLPrefix: 'https://www.mydomain.com/'
    }))

We can see the result in this screenshot:

Ultimately, the requirements for our projects will determine how source map support needs to be configured—we may even have to go as far as compiling multiple files into one larger master file, if our project requirements dictate.

There's one thing to bear in mind, though—there are plans to include native source map support in Gulp 4; this will likely mean that the need for a separate plugin will become redundant. It pays to keep abreast of changes, particularly if it might affect our processor!

Let's change tack at this point, changing the source map compilation process was a straightforward alteration. We can take it up a notch with another key area—vendor prefixes. We've already covered the basics, so we'll take a look at how we can improve support.

Aha, prefixes! The bane of any designer: adding them and keeping them up to date can be a real chore.

The autoprefixer task that has already featured throughout these pages goes some way to reducing the burden: it will add the current prefixes and remove any that are no longer needed. This is good…but we can do better! This time around, though, the emphasis is less on code, and more on the kinds of decisions we need to make:

It's not obligatory, but it at least makes it clear! If we wanted to be real purists, we would split this task into two separate ones, so that we're keeping to the one task: one role mantra:

It goes without saying that vendor prefixes continually change; with careful planning and the right use of plugins, we can be safe in the knowledge that no matter what happens, our code will be updated at the next compilation.

Now, moving on: I am sure you are familiar with the ubiquitous pseudo-selector, such as hover. This is one area where we need to carefully consider what we might incorporate into our baseline processor; PostCSS has a number of plugins that can facilitate handling pseudo-selectors in our code. Let's take a look at this in more detail.

When designing sites, pseudo-selectors are a key part of providing interaction—they can be anything from the simple hover, all the way through to newer elements such as :range or :placeholder. We also have to be mindful of support—thankfully most elements will work in reasonably recent browsers (yes, even IE8!), but not all browsers use the same format of single or double colons when referencing the selector in CSS.

To help with both styling and providing consistency, PostCSS has a number of options we can use; we will explore using the postcss-pseudo-elements-content plugin in a moment, but for now, let's take a quick look at some of the options to give you a flavor of what is available:

This is just a small selection of the handful of plugins currently available in the PostCSS ecosystem, for handling pseudo-selectors. We can talk about using them, but in reality, the best way to understand their usefulness is to see them in action! With this in mind, let's take a look at one in action: postcss-pseudo-elements-content. This little beauty has but one purpose in life: to add a content: attribute to appropriate pseudo-selectors, if one is not present in our code.

There are a few examples of plugins that help handle pseudo-selectors better; our projects will dictate whether we should use them on a per case basis, or can incorporate some or all of them into our baseline processors.

One example that might suit being added to our baseline processor is postcss-pseudo-elements-content, which is available from https://github.com/omgovich/postcss-pseudo-elements-content. This simple plugin parses our code and will add a content: '' statement to our code, when it sees instances of appropriate pseudo-selectors. It doesn't require any configuration, so without further ado, let's get stuck into using it:

If all is well, we should see something akin to this:

In a sense, this could be treated as a shortcut plugin (in a similar fashion to ones we worked with earlier in the book). The magic happens by adding –c after our pseudo-selector, as shown in this code extract:

.underline a:hover::after-c, .underline a:focus::after-c {
  opacity: 1;
  transform: translateY(0px);
}

When compiled, it adds the content: '' attribute, as shown in this screenshot:

Although it is debatable whether it is worth adding a plugin for something this small, it does at least ensure that we keep a consistent code base when compiling our style sheet.

The real decision is whether your code has sufficient instances of pseudo-selectors to warrant installing these plugins as part of a baseline, or if your projects dictate their use on a case-by-case basis.

Let's change tack, most of the improvements we've covered relate to text. Text sites can be very unappealing without images—thankfully, there are some plugins available to help extend our baseline processor, and better manage images. I feel a demo coming on, so let's go explore this in more detail.

If we were to consider our processor as being solely for compiling PostCSS code, then we are selling ourselves short—we've already covered how the use of a task runner such as Gulp allows us to add additional tasks such as autoprefixer and cssnano.

A great one to consider adding is the ability to compress our images for optimum size; would you want to do this manually, no matter how much or how little might be saved in size? I thought not. Automating this process means we can get on with tasks that add more value to the process. We can achieve this with the gulp-imagemin plugin, available from https://github.com/sindresorhus/gulp-imagemin—let's take a look at what might be involved in minifying our images:

If all is well, we should see our newly compressed images in the img folder—this is a useful task to have within our processor, so let's go through a few points in more detail.