How I effortlessly draft and maintain squeaky-clean CSS with SASS and

One problem I have increasingly faced over the past four years or so, as my websites became more complex, was the need to maintain a large, constantly-evolving and unwieldy set of stylesheets. I’ve been writing all the code for this myself for some time now. Every few months, I have tended to rethink the structure of my main site: design standards evolve so fast that I find I need the constant challenge of starting from scratch, just to keep on top of the phenomenally rapid pace of change in an industry in which nine months are akin to a lifetime.

The difficulty of maintaining several stylesheets at once

Until now I hadn’t invested much thought in the tools I used for writing and maintaining my code: I did switch from a Textmate/Transmit combo to the all-purpose Coda a couple of years ago, and last year complemented this with Espresso as a way of testing CSS before it went into production. But the current spate of frequent design revamps has put strain on this carefree approach, essentially because I have been maintaining three separate stylesheets for (i) the home page, (ii) the contact form and (iii) posts and pages: there wasn’t that much overlap between these three stylesheets, so it made sense to keep them separate and small—but this came at the cost of considerable pain whenever new versions were required. Ensuring the three stylesheets were consistent ended up wasting so much of my time I spent some time looking into ways of getting the job done more efficiently.

The tech sector isn’t lacking in imagination, and quite a large number of new tools have emerged in the past few months to make code editing and maintenance more efficient. The ones I’m actually using include the following:

What CSS preprocessors can do

Reading about the latter, in particular, set me thinking about ways of making my CSS leaner and more future proof. Essentially this meant making the static content in my stylesheets dynamic, so that the process of drafting, storing and updating them could be made automatic and consistent: and the solution was to switch to using a CSS preprocessor [i] with this exact purpose. My objective was pretty well summed up by Aaron Ackerman on his blog NittygrittyJS:

CSS preprocessors are starting to become more apparent to a lot of developers. The point of them is to write less source code that maps to greater source code, but is hopefully more readable, understandable and programmatic. For example grid layout are very easy when a preprocessor can divide a full content width into a number of columns. Using variables can help keep colors consistent by always referencing a number of preset variables. Using mixins can prevent us from having to rewrite code and letting the preprocessor do it for us. Preprocessor are simply reaching for what CSS should already do. There have been proposals for this to happen in CSS but the indecision for the CSSWG has slowed this down considerably. But why not use some form of it now? We can use a preprocessor syntax can compile to CSS that works today.


When Alexis Sellier’s LESS, was launched I had taken a close look at it, liked it but, doubtless through sheer apathy, never got round to using it. I eventually got kicked into action a couple of weeks ago, after reading a rather thoughtful post by Ken Collins, who makes a forceful case for SASS and Compass over LESS:

I want to treat CSS as a language and use features like loops, lists and custom functions.

Smashing Magazine published a rather good comparison by Jeremy Hixon, An Introduction to LESS, and Comparison to SASS, which decided me in favour of SASS as being the easiest way to migrate my existing CSS, into which I’d already put a lot of effort, to the discipline of a preprocessor.

The reasons for using Compass

I chose to apply SASS using Compass, an open-source CSS authoring framework: it comes with a number of built-in modules that you can choose to include in your build, or you can build your own if preferred. I decided to install, a powerful yet unobtrusive menubar utility meticulously developed and maintained by Handlino for Sass and Compass that helps designers compile stylesheets easily without resorting to command line interface. brings support for two additional design frameworks, 960 Grid and html5boilerplate, in addition to Compass’s built-in extensions, Blueprint and Compass [ii]

Compass will set up a directory structure corresponding to the type of project you’re building (960 Grid, html5boilerplate, etc.) and you can then work from those files—in which you’ll be able to use the powerful SASS markup—to achieve the desired stylesheet while keeping control of it.

Fine-tuning your code with partials

To make the most of Compass, I found it best to divide up my stylesheet into ‘partials’, prefixed by an underscore and stored in a separate partials folder. Each partial file can be made up of styles fitting a pattern. My current list looks as follows:

  • _author-reset.scss
  • _banner.scss
  • _base.scss
  • _basic-reset.scss
  • _contact.scss
  • _fonts.scss
  • _helpers.scss
  • _home.scss
  • _media.scss
  • _mixins.scss
  • _overrides.scss
  • _primary-styles.scss
  • _search-box.scss
  • _sidebar.scss
  • _single.scss
  • _sitewide-styles.scss
  • _style.scss [iii]

The Compass client will continually ‘watch’ the folder in which you’re working for any changes to any of your .scss files. Whenever you save them, it will update your actual .css files, which are stored in a separate folder:

The way Compass works
The way Compass works: you store each component of your stylesheet in a partials file. Your main css files will automatically be compiled by Compass in valid CSS from the corresponding scss files concatenated from the various components in the SASS folder

If a bug finds its way into your scss files, it’ll never get into your css: SASS will flag them when you save the file, and will display a warning message, usually explaining what you got wrong. This is an incredibly useful feature.

SASS’s most powerful features turn it, effectively, into a dynamic language

SASS is incredibly powerful and there’s almost no limit to what you can make it do dynamically to your css. I made most leverage of two features: variables and conditional statements.


In my _base.scss, I created a wide range of variables, effectively allowing me to update my css by just applying the change to a single item—with SASS and Compass then doing the hard job of meticulously impacting each selector in all my style sheets accordingly, if required:

The variables stored in my _base.scss file include:

  • paths for the CDN and image folder;
  • the main site proportions and sizes (body width, page width, etc.);
  • variables for each colour used, where possible expressed in relation to one another;
  • colour definitions for any text not in the default body text colour;
  • font sizes and definitions;
  • data urls.

Conditional statements

Possibly the most powerful feature of SASS is its ability to follow conditional statements.

In SASS, after the @if keyword, we can put a statement that will be evaluated as either true or false. If the statement is true, whatever is inside the following declaration block will be executed. I made extensive use of this to turn the stylesheets into, effectively, a dynamic code component in much the same way as PHP.

First, I declared three different values in each of my scss files for a variable called $stylesheet-type: basic, contact and home. For instance the content of the home.css file was as follows:

/* Define the stylesheet as the home page sheet */
$stylesheet-type: "home";
/* Include all the content of the _style.scss file after processing */
@import "partials/style.scss";

I then scanned my scss partials, marking up (a Textexpander shortcut made it painless) code according to whether it was required in one, two or three of my css style sheets, like this:


@if $stylesheet-type == basic {

    /* Any styles appearing here will only be included in style.css */




@if $stylesheet-type != home {

    /* Any styles appearing here will ONLY be included in style.css and contact.css */



In this way, once I’ve applied any changes I need to the variables, added, removed or amended selectors in my partials files, the mere click of a button will result in compiling three perfectly-drafted stylesheets,one for each scss file in the project. can be set to output CSS in compressed, compact, extended or nested format, depending on taste. I personally like to put them in production compressed, since the process of drafting and editing them is so heavily automated that this involves no extra work or risk at all. I find that I’m now able to work on new projects much faster than I did before. It’s fair to say that using SASS and Compass has radically changed the way I organise my life.


  1. This article by NetTuts gives the clearest possible definition of what a CSS preprocessor is and what the various options on offer are. []
  2. You can also add your own additional third-party extensions to if desired. []
  3. _style.scss (with an underscore) is different from style.scss (without an underscore), since partials, unlike full scss files, are only used as feeders for full SASS files and will not be compiled into css files. []