Chapter 9. Becoming a Sass and Compass Power User

In many ways, the techniques we looked at in the last chapter are power user techniques. So why is this chapter called Becoming a Sass and Compass Power User? Two reasons.

Knowing so-called 'power user' techniques is one thing. However, to be truly great with a tool, requires the restraint and wisdom to know when and how to employ that tool. Therefore, before unleashing our new skills on the wide world of the Web, I think it's important we foster a 'power user' mindset to accompany them. This will include reviewing our code and considering some techniques to test and analyze our work before deploying it. That way, we will have the knowledge to understand the effects of our actions. That, my friend, is being a power user.

Secondly, this chapter won't be short of new Sass and Compass goodness. There'll be power user tricks oozing out of every fiber of this chapter. However, the new tricks and techniques we will learn in this chapter will be the...

Turning off Compass support for specific vendors

With experimental CSS properties, it's normally necessary to use a vendor 'stack'. In a worst-case scenario, that means adding a vendor prefix version of a property for every vendor that support is necessary for.

Here is a (non-working) example with a vendor prefix for WebKit (Chrome, Safari, and now Opera too), Mozilla (Firefox), Microsoft (Internet Explorer), Opera (legacy versions), and finally the non-prefixed (official W3C) version:

.example {
  -webkit-property: 1px;
  -moz-property: 1px;
  -ms-property: 1px;
  -o-property: 1px;
  property: 1px;
}

In reality, different vendors are seldom at the same point of implementing experimental CSS features. Although it may be necessary to provide a vendor prefix for one vendor, it may not be for another.

To exemplify this, while Internet Explorer 9 had no support for CSS gradients (http://www.w3.org/TR/css3-images/#gradients), Internet Explorer 10 supports the official un-prefixed version. Therefore...

Adding experimental support for bleeding edge CSS features

These days, CSS specifications are moving fast. It seems like every day there is an amazing new feature to try out. How can Compass keep up? Sometimes it can't but that doesn't mean it hasn't got us covered when it comes to providing support for experimental features it hasn't already got a prewritten mixin for.

Let's indulge a brief fantasy. A new property has been announced that will automatically add images of sausages behind elements. I know, I know, it'll be a massive time saver.

If such a thing did exist, here is how we might use Compass to add experimental support for different vendors:

.your-own-property {
  @include experimental(sausage, lincolnshire);
}

And here is the CSS that produces:

.your-own-property {
  -webkit-sausage: lincolnshire;
  -moz-sausage: lincolnshire;
  -ms-sausage: lincolnshire;
  -o-sausage: lincolnshire;
  sausage: lincolnshire;
}

Tip

Remember, the vendor stack produced will match what has been set with...

Defining experimental values

Super, that has us covered for experimental properties. But what do we do if the value itself is experimental? After all, given our prior example, I'm almost certain I've not set the value of a property to lincolnshire before now (float: lincolnshire; anyone?).

Compass has a mixin to cover that. It's called experimental-value. Take a look at this example:

.your-own-property {
  @include experimental-value(sausage, lincolnshire, -moz, -webkit, not -o, not -ms, not -khtml, official);
}

Here is the CSS that generates:

.your-own-property {
  sausage: -webkit-lincolnshire;
  sausage: -moz-lincolnshire;
  sausage: lincolnshire;
}

As before, it respects any global vendor support you have set alongside ones explicitly passed in as arguments.

The Sass interactive shell

By now, hopefully the Command Line Interface (CLI) doesn't seem like such a scary place. Just as well. There's a great and lesser-known Sass feature called the Sass 'interactive shell' that requires it. Let's give it a whirl.

Open the command line. Now type:

sass –i

A double-angled bracket will display like this:

>>

Excellent, we're in. Now, let's get geeky. Type this and press Enter:

mix(#fff, pink)

A result is 'printed' back on the command line:

#ffdfe5

How about that? The Sass interactive shell allows SassScript computations to be performed directly on the command line. Therefore, alongside any of the math we looked at in the last chapter, any of the Sass-based (but not Compass-based, more of that in a moment) color functions from Chapter 4, Manipulate Color with Ease, can be used directly in the Sass interactive shell too.

To finish working in the Sass interactive shell, just press Ctrl + d together to be returned to the standard command line.

I'll be honest, with...

Adding the Sass globbing plugin to import batches of partial files

For users who like to break their style sheets into numerous partial files, it is worth knowing that folders full of partials can be imported using a single line of code. For example, at present in the styles.scss file, we have the following imports listed:

@import "partials/variables";
@import "partials/mixins";
@import "partials/fonts";
@import "partials/normalize";
@import "partials/base";
@import "partials/placeholders";
@import "partials/bb-grid";
@import "partials/layout";
@import "partials/modules";
@import "partials/chapter-examples";

Instead, to import all of those partials in one go with Sass globbing, we could do this:

@import "partials/*";

However, before proceeding, know two things. Sass globbing requires installing the Sass globbing plugin (no big deal). More importantly, with globbing, files are imported in an alphabetical order. This second point is particularly important.

If the order of imports is important...

Creating multiple separate style sheets

The following is perhaps obvious but I feel worth explicitly stating. Suppose the need arises to supply two separate style sheets. Maybe one for small screen devices and another for large. Or perhaps one set using data URIs for image assets and another without. Whatever the reason, generating multiple, separate, CSS files can be achieved easily with Sass. Any Sass (for example, ending in .scss) file in the project that isn't defined as a partial (remember, the underscore before the filename indicates it is a partial) will automatically be compiled to a CSS equivalent.

Therefore, if there were three files (for example styles.scss, nav-png.scss, and nav-svg.scss) in the Sass folder, three CSS files will be generated (styles.css, nav-png.css and nav-svg.css) respectively from them.

Converting partial files to standalone style sheets

Remember that it's also easy to create a standalone file from an existing partial file. Just omit the leading underscore from the filename. So a file called _navigation.scss could be renamed navigation.scss and this would compile to navigation.css (if the file is still within a folder named partials, it will also be generated within the CSS folder in a subfolder called partials).

Note

There have been whispers in dark corridors (alright, not really, just on GitHub) that the possibility may exist in future versions of Sass to target particular styles to particular style sheets. Those curious may wish to read the following threads: https://github.com/nex3/sass/issues/241 and https://github.com/chriseppstein/compass/issues/664 on the Sass and Compass projects respectively.

Compass statistics

I love a good set of statistics. It turns out that Compass does too. Alongside all its other wonderful capabilities, Compass can produce statistics about a project in seconds. I like this a lot. Let me share how it's done.

Tip

For a reminder about how to move around the command line, refer back to Chapter 1, Getting Started with Sass and Compass. In that chapter, we had a basic overview of how to switch folders on the command line.

First, it's necessary to move to the root of the project. The config.rb file lives in the root, so that's an easy flag to indicate you're at the right 'level'. When at the root of the project, run this command:

compass stats

And check out the results:

Lovely! Compass has effortlessly produced an overview of which files contain the most mixins, properties, rules, and a whole lot more. On a larger project, such information can be very instructive. However, notice that there are no statistics for the compiled CSS. Thankfully, a friendly message at the...

Clearing the Sass cache

Sass uses a cache system (stored in the invisible .sass-cache folder) to speed up the creation of CSS. Very occasionally, something goes wrong in Sass and Compass land. Maybe the CSS won't generate when the Sass files are saved, or perhaps the wrong styles seem to be getting generated. If things are going pear shaped and it's not an error between the keyboard and chair, it's possible to force a clear of the Sass cache using a Compass command.

It's no exaggeration to say I've used this command less than a handful of times. However, on the off chance you need it, from the CLI, move to the root of the relevant project and run this command

compass clean

Tip

Alternatively, you can just delete the .sass-cache folder manually (it's a hidden folder by default that lives in the root of the project) and it will be regenerated next time the Sass compiles.

One-off Compass compiles

Compass can compile to different output formats as 'one-offs'. For example, suppose while developing, it would be handy to check what the minified file size of the generated CSS is. Rather than alter the config.rb back and forth, we can achieve this with a command:

compass compile --output-style compressed --force

Similarly, if working with a compressed output style as standard, a one-off expanded compile could be generated as follows:

compass compile --output-style expanded --force

Mission debrief

We've covered a lot of Sass and Compass ground in our time together. At this point in building up the style sheets for http://sassandcompass.com, I feel the Pareto principle is coming into effect; we've covered 80% of the work with 20% of the effort. Rather than enduring the final section (sure to involve me making all manner of tedious mistakes) that wouldn't really offer any insights into using Sass and Compass, I'll be happier for you to simply grab the complete code download from the site itself.

Instead, at this point it will be more instructive to try and circumvent and address any issues we have introduced with all we have already done.

Fixing human errors

Remember that even with strong Sass and Compass-fu skills, it doesn't prevent human errors being introduced into the code. Therefore, when I feel like a project is around 70-80% styled (conveniently, the place we find ourselves), I like to take a good look at the compiled CSS and clean up all my usual schoolboy errors...

Avoid conjecture with tools and testing

There have never been better and more accessible tools for testing CSS code before deployment. As such it's possible to supplant common performance generalizations with empirical facts. Performing tests provides actual data on which to base choices, rather than relying on mere conjecture.

To exemplify this, it has been a long-held belief that certain CSS selectors are 'slow' compared to others, the much maligned universal selector is an obvious example. Some would also argue that it would be better to use a qualified selector such as footer[role='contentinfo'] rather than merely [role='contentinfo']. The theory is that in the case of the latter, the selector engine has to travel every DOM node. However such rules are typically based on generalization. For your own project, any performance difference may be of little to no consequence and the benefits of a particular selector (maintainability, low specificity) may outweigh any expected performance...

Parting shots

Now that we have looked at how to quality check our style sheets and performed some testing to make it more performant, let's bring things back to Sass and Compass. Grasshopper, before we say 'sayonara', I'd like to remind you that getting the most out of Sass and Compass isn't about employing every single feature at every single opportunity. After all, it's supposed to make authoring style sheets easier and more enjoyable.

Therefore, when using it for the first time on a live project, only use the things that actually help you. Don't worry if writing a mixin to produce a certain set of styles doesn't work straight off the bat. Enjoy the things that help right away. Perhaps it's as simple as defining all the project's colors as variables, or simply producing cross-vendor CSS effortlessly with some existing Compass mixins. Grow your confidence in wielding Sass and Compass to make life easier first and foremost and then throw in the extra ingredients (loops, globbing, sprites...

Summary

I'd like to share a quote from Michael Crichton's book Jurassic Park:

Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.

This is instructive, not just of the incredibly highbrow prose I read, but perhaps also the situation you now find yourself in. If your humble author has done even a half decent job, you should have gained an understanding of most of the major functionality and techniques available when using Sass and Compass to author style sheets.

Just be mindful that although we have these skills and techniques at our disposal, this doesn't necessarily mean they are right to use all the time.

Practically, we have already considered that things such as over-nesting rules can produce anti-patterns in our generated code. In the same vein, consider whether other practices that are now more easily achievable with Sass and Compass are actually the right choice. In-lining a 1 MB image as a data URI in your CSS wouldn't be a smart...