Introducing the CSStyle library

Cast your mind back to Chapter 3, Nesting Rules, where we explored the concepts behind BEM, or the Block, Element, Modifier way of writing CSS. The key benefit of using this method is to help reduce CSS specificity, or where we might otherwise end up using something such as the following to style a simple button:

#maincontent .button .red.large:hover

Okay, it's a little contrived, but you get the idea: the level of specificity makes it awkward to manage and potentially reuse in future projects.

We took a look at BEM as a possible alternative—it has the benefit of reducing styles down to one or two classes, but can be awkward to remember which conventions to use:

.component {
  /* represents a component */
}

.component__element {
  /* represents a small part that is used to make a component */

}

'.component--modifier {
  /* represents a state modifier for the component */
}

Okay, so how can we get around this? Well, here's an option we can consider using: the CSStyle library. There are several reasons why this can help us—let's take a look in more detail.

Exploring the benefits of using CSStyle

The key behind CSStyle (available from http://csstyle.io/) is that it is made up of modular blocks, in a similar fashion to BEM. The difference, though, is that instead of having to remember a set of conventions that aren't the most intuitive, we can use a simpler set to create cleaner code.

The real beauty, though, is that we can use either SASS or PostCSS to create our site—we can begin with SASS, but we can also begin to transition over to using PostCSS with minimal changes. Let's put this into practice, and explore a quick demo to see how easy it is to make these changes—before we do so, take a look at http://codepen.io/alibby251/pen/pgmqjJ; this is a Pen that illustrates what we're going to create:

It won't win any style awards, but the purpose of this demo is to show you the process and not necessarily produce anything that is stunning! With that in mind, let's make a start:

We'll begin by extracting a copy of the T56 - using csstyle with sass folder from the code download that accompanies this book; save the folder to the root of our project area.
Copy the contents of the src folder within T56 - using csstyle with sass to the src folder at the root of our project area.
Go ahead and replace the gulpfile.js and package.json files at the root of our project area with copies from within the T56 - using csstyle with sass folder.
Fire up a Node.js command prompt session, then change the working folder to the root of our project area.
At the prompt, enter gulp and press Enter—if all is well, we should see a compiled style.css file appear in the dest folder in our project area.
Copy the contents of the dest folder back to the css folder within the T56 - using csstyle with sass folder.

At this point, try previewing the results in a browser. If all is well, we will see the three buttons appear, just as they show in the Pen we mentioned at the start of this exercise.

All looks good…we have a working demo, with a compiled style sheet—but hold on…in SASS? Yes, if you look carefully, the demo was indeed set to use SASS, but with good reason: we're going to see how easy it is to change to using PostCSS without making material changes to our style sheet or our compilation process. Let's make a start:

In the gulpfile.js that is at the root of our project area, comment out line 5, and uncomment lines 6 and 7; this switches our task file from using SASS to PostCSS.
Rename the [sass] task [style], on line 9.
On line 10, the gulp.src call is looking for SASS files; change it to src/*.css.
Replace line 11 with this line: .pipe(postcss([nested, csstyle]))—this removes the dependency on SASS and switches to using PostCSS.
On line 15, our default task will call the [sass] task; change [sass] to [style].
Change the watch task on line 17 to monitor CSS files, and not SASS:
```
var watcher = gulp.watch('src/*.css', ['style']);
```
Go ahead and open up the SASS style sheet in the src folder at the root of our project area—rename the file as style.css.
In style.css, go ahead and remove the @import 'csstyle' line at the top of our style sheet.
Do a search and replace for @include—remove all instances in our style sheet.

That's it for our demo, sorry to disappoint if you were expecting more! All that remains is to replace the gulpfile.js and package.json files at the root of the project area with copies from the T57 – using csstyle with postcss folder, and compile as normal.

Dissecting our demo

Making the transition from SASS to PostCSS can be as easy or as complex as we make it. Using the CSStyle library can go a long way to easing the transition away from existing processors such as SASS.

Although our demo was just a quick whistle-stop tour through using CSStyle (and we will revisit it in Chapter 12, Mixing Preprocessors), it nevertheless illustrates a few important points of interest:

The library uses the concept of components, options, parts, and tweaks to create the base components, pass styling to override base rules, add extra elements (such as icons), or tweak code. Careful design means that we can reduce or remove the need to alter our HTML as part of the transition to using PostCSS.
It is perfectly possible to compile the SASS version of our demo using a standard SASS compiler; the reason for choosing to use a task runner version (in this case for Gulp) means that we can centralize the compilation process in one task file, and remove the need to use separate compilers in our process.
When planning the design or transition of our site to use PostCSS, it pays to choose plugins carefully within PostCSS; this will determine how easy or complex it will be to make the changes in our code and processor.
Our demo focused on the core compilation process, and didn't include the extra tasks we used in the past, such as adding source maps. This was purely for clarity—there is no reason why we can't add the remaining tasks we've used before, once we've confirmed our compilation process works as expected.

Ultimately though, the use of this library is about helping to ease the process of making the transition to using PostCSS. There are different ways to approach this—using CSSStyle means that we have to completely redesign our HTML, but can easily alter the processor with minimal fuss. The flip side to this is that we can use PostCSS plugins that mimic SASS coding standards, or create our own custom syntax—we will explore these concepts in the next two chapters.

Previous Chapter

Getting started with some hints and tips

Next Chapter

Summary

Table of Contents for Mastering PostCSS for Web Design

Introducing the CSStyle library

Exploring the benefits of using CSStyle

Dissecting our demo

Table of Contents for
Mastering PostCSS for Web Design