Use a CSS Preprocessor

CSS Preprocessors have been around for a while now, but I didn’t start seriously looking into them until about a year ago. I have loads of excuses for this: I was too busy, I already knew how to write CSS, cool kids write their CSS by hand… you get the idea. Basically, I didn’t think yet another language like LESS, Stylus or Sass would have anything to offer me.

I was wrong, and CSS Preprocessors are awesome. Here are three good reasons why.

You Already Know A Lot

If you already know a decent amount of CSS, guess what? Congratulations! You also already know a good portion of LESS and Sass as well.

In both languages, CSS is perfectly valid to write. So when you want to bold a tag, this is what your Sass would look like:

strong { font-weight: bold; }

That’s 100% homegrown CSS there, folks. Because Sass and LESS are CSS fundamentally. Just like you can write normal JavaScript in your jQuery, you can write CSS in your preprocessor of choice.

This is awesome because it means you don’t have to spend hours learning a new syntax just to spit out the clichéd “Hello World” page. You can write what you know, and add in the new syntax as you learn it.

CSS3 Is Hard

So here’s the thing: I build websites for a living and I write about building websites in my free time. And yet when it comes time to craft a cross-browser CSS linear gradient on my site, I’m pulling up Google just like 99.9% of the other developers out there. Because with the extra power we have with CSS these days comes great complexity.

Take a look at this CSS for a simple blue background gradient:

.gradient {
  background: -moz-linear-gradient(top, #1e5799 0%, #7db9e8 100%);
  background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#1e5799), color-stop(100%,#7db9e8));
  background: -webkit-linear-gradient(top, #1e5799 0%,#7db9e8 100%);
  background: -o-linear-gradient(top, #1e5799 0%,#7db9e8 100%);
  background: -ms-linear-gradient(top, #1e5799 0%,#7db9e8 100%);
  background: linear-gradient(to bottom, #1e5799 0%,#7db9e8 100%); 
}

And no, I didn’t write that by hand. I can’t remember the intricacies of that sort of syntax. I nabbed it from ColorZilla like a sane human being.

And yet, what happens when we use Sass (with its fantastic helper, Compass)? Magic:

.gradient {
  @include background-image(linear-gradient(#1e5799 0%, #7db9e8 100%));
}

One line of code. And it’s simple enough I can memorize the syntax. And then when I compile my Sass, it spits out CSS just like the CodeZilla-spawned code soup above.

Variables and Mixins ROCK

Remember when you very first started hearing about CSS, and the promise of how it was going to simplify your development? You write one simple rule, and the resulting style magically cascades down through your document. Brilliant!

But why is it that the mojo of the cascade still leaves us repeating chunks of code throughout our site? Why do we find ourselves scattering colors, padding widths and font sizes in a half dozen places in the same stylesheet?

Preprocessors solve that by giving us variables. We’ll extend our gradient example:

$lightBlue: #7db9e8;
$darkBlue: #1e5799;
.gradient {
  @include background-image(linear-gradient($darkBlue 0%, $lightBlue 100%));
}
a { color: $darkBlue; }

We define a variable at the top of our stylesheet, then use it wherever we want. Now when your client comes back and says he wants that blue to have a teensy bit more green in it, you don’t have to find it in a half-dozen places. Change the variable and be done with it.

Mixins can be even more helpful. In Sass they are particularly powerful, acting almost like functions. If you find yourself using the same set of rules repetitively, mixins are for you. Here’s a super simple mixin I use on CSS Newbie:

@mixin inline-block {
  display: inline-block;
  *display: inline;
  zoom: 1;
}

This is a fix for inline-block in IE7 (which doesn’t understand inline-block, but will treat inline elements with layout like an inline-block element anyway). Any time I want an element to be inline-block, I use this mixin, like so:

.site-logo {
  @include inline-block;
}

And now my inline-block elements work all the way back to IE7, without me having to write out a bugfix each time.

The List Goes On and On

These are just three of the many reasons to use a CSS Preprocessor. Others include code nesting (which just makes sense, dammit) and built-in compression to reduce file size and speed up your site.

I’m not going to tell you here which preprocessor to use. I’ve used LESS in the past and mostly use Sass currently. In my opinion LESS is a little easier to learn and Sass is a little more powerful, particularly when paired with Compass. And there are others out there (Stylus has a strong following but I’ve not used it). But what I will tell you is to use one. There are lots of reasons to do so, and not very many good reasons not to.