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.