Discovering Compass
This is post about a CSS preprocessor; a controversial subject it seems that divides the web design community. I’m not going to go into the details of why you should or should not use a CSS preprocessor–plenty has already been written on that subject, including on this very site–and I’d suggest that you try one for yourself and make your own mind up either way. Personally I’ve been using Sass for a few months now and I’m totally sold on it, but one of the major selling points for Sass is its mysterious companion: Compass.
OK, so what is Compass?
Up until a few days back, I only had a vague idea of what Compass actually is. Sure, when I’d installed Sass via the command line (in those crazy times before CodeKit) Compass had also come along for the ride, and I’d seen tweets from various respected commentators singing its praises, but I’d never really known what it was intended for. So I set about delving into it and seeing what’s what. Here’s what I’ve found out so far…
As a simplified explanation, Compass is a framework of ready-made mixins (patterns of common and useful CSS) that you can integrate into your Sass projects. This cuts down on a lot of repetitive work that you would otherwise end up doing time and again across various web projects. Importantly, you are not locked into the framework – you can use as many or as few of the mixins as you wish, alongside your own mixins and CSS. And since Sass is compiled locally before you upload the final vanilla CSS files to your site, it will only include code from mixins that you have actually used in the project–any other used mixins will be ignored and omitted from the CSS, keeping things lean.
You may be thinking: but I can already find a huge number of Sass mixins for public consumption on the internet, why is this any different? Well for one thing, Compass is developed and curated by Chris Eppstein, one of the core Sass team, so there’s probably none better placed to understand what makes a good Sass mixin than he. Chris also encourages contributors to suggest additions and improvements to the core mixins, as well as integrating patterns from other popular frameworks such as Blueprint and H5BP.
Vendor prefixes, the stuff of nightmares?
Another huge plus for Compass is on the thorny subject of vendor prefixes, a subject that almost eclipses CSS preprocessors in it’s ability to induce nerd-rage (and rightly so). CSS3 is still a moving target and browser vendors are implementing new features, changing existing features and ‘embracing and extending’ the spec on what seems like a constant basis. The gradient syntax has been a perfect example of that.
Consider my current Sass mixin for a linear-gradient:
@mixin gradient($color-gradient-from, $color-gradient-to) { background: { color: $color-gradient-from; /* Konqueror */ image: -khtml-gradient(linear, left top, left bottom, from($color-gradient-from), to($color-gradient-to)); /* Safari4+, Chrome */ image: -webkit-gradient(linear, left top, left bottom, from($color-gradient-from), to($color-gradient-to)); /* Safari5.1+, Chrome10+ */ image: -webkit-linear-gradient($color-gradient-from, $color-gradient-to); /* Firefox3.6 */ image: -moz-linear-gradient($color-gradient-from, $color-gradient-to); /* IE10 */ image: -ms-linear-gradient($color-gradient-from, $color-gradient-to); /* Opera11.10+ */ image: -o-linear-gradient($color-gradient-from, $color-gradient-to); /* CSS3 Compliant */ image: linear-gradient($color-gradient-from, $color-gradient-to); } /* IE7-9 */ filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#{$color-gradient-from}',EndColorStr='#{$color-gradient-to}'); }
Which I can then invoke in my Sass-flavoured stylesheet like so:
.gradient-example { @include gradient; }
All well and good, but that relies solely on me keeping up-to-date on where we currently are with vendor prefixes for at least 7 browsers–possibly more in the future–and then modifying my mixin across all my projects if and when a change in the syntax takes place. It’s also not that flexible–I’ll have to write another mixin if I want the gradient to flow differently, or if I want radial gradients.
With my project running under Compass, I can instead use this rule in my stylesheet:
.gradient-example { @include background-image(linear-gradient(left top, $color-gradient-from, $color-gradient-to)); }
Or if I want a radial gradient:
.gradient-example { @include background-image(radial-gradient(45px 45px, $color-gradient-from 10px, $color-gradient-to 30px)); }
Compass does all the heavy lifting for me, I won’t go into detail on the mixin code it uses, but suffice to say it’s a lot more clever than what I’ve been using. If any of the prefixes or gradient syntax changes in the future, no problem–as long as I’m running the latest release of Compass all I’ll need to do is recompile the project again (a matter of seconds) and be happy in the knowledge that minds immeasurably superior to mine have already included this change in the framework… Compass has got my back, basically.
Are there any disadvantages?
As with the debate about CSS preprocessors in general, Compass is not a magic bullet that means you don’t need to learn and understand CSS in order to use it. There can be the temptation for users to lazily nest selectors where there really isn’t any need to do so, introducing potential specificity issues and unwieldy final code. Not really a fault of preprocessors per se, but they do make it easier for you to be sloppy.
There’s also the valid argument that you’re losing that fine-grained control of your own CSS; take this simple Compass mixin example that can be used to hide text (a bit like the older text-indent:-9999px rule):
#logo { @include hide-text; }
Which produces this CSS:
#logo { font: 0/0 serif; text-shadow: none; color: transparent; }
Looks fine, but what if my text never had a text-shadow rule applied to it in the first place? We’ve just introduced a new rule to nullify a rule that was never there. A needless extra line of CSS.
That’s the rub I’m afraid. You need to be selective over the mixins you choose and make decisions on whether a slight bit of extra code is acceptable in any given task. That example above is a pretty minor case but since the Compass mixins have to be all things to all people, there will undoubtably be occasions where a number of rules within a mixin will not be directly related to the CSS code you have written. Of course, going back to my earlier point, you can use as many of the Compass supplied mixins as you want and still use your own mixins too so that can be negated somewhat.
How to start using Compass
Until recently you’d need to install Ruby and some Ruby gems, then run the framework from the command line. You can still do that of course. However, as I’m a long-term Mac user and scared of anything without a GUI layer, I’d recommend Compass.app by Handlino which works on PC, Mac or Linux, or CodeKit by Bryan Jones which is only available on a Mac. Both make it incredibly easy to get a Compass project up and running. There’s probably other apps available that fulfill the same task, and I apologise in advance for not mentioning them, but those are the two I have used myself.
The reference for all current core Compass mixins are listed on the Compass website, as are mixins for Blueprint. It may take you a while to learn all the available mixins but it’s well worth the time to scour those reference pages. However, I did find it easier to clone the Compass GitHub repo and peruse the /frameworks/compass/stylesheets directory in order to find all the mixins quickly.
Further investigations
I’m sure I’ve only scratched the surface of what Compass can do, and I’m certainly no expert on it–that’s why I’m writing about it here on 12412. If and when I find out more I’ll post another article. In the meantime, feel free to leave any comments you have on Compass. And no, I don’t care whether Less or Stylus are better than Sass. There, I said it (but I’ve provided links to both of them here for balance)!
Leave a Reply