CSS Preprocessor: Sass

Sass, LESS and Stylus are what’s known as a CSS preprocessor, or as I like to think of it, CSS shorthand. A preprocessor is a meta language that's used to extend the vanilla CSS language. The unique syntax allows you to write CSS more quickly and efficiently through the use of nested rules, variables, mixins, functions & operations and more. The preprocessor syntax however is not readable by browsers so it's essentially useless until it’s been converted into the CSS language we know and love. This is what compiling does and it's simple to do.

More or LESS Sass

My first preprocessor experience was with LESS. I used it on and off for a year and liked it, though I never fully committed to it. Nevertheless it is a remarkably useful tool and is the one that got me hooked on preprocesors. But that’s not what I thought at first:

I have to learn a different CSS syntax just so it can be compiled into what I would have written in the first place? Seriously? Are you kidding me?

As preprocessors quickly became mainstream tools for designers and developers Sass always seemed to be the most talked about. But what really caught my interest were the interesting tools that could be used in conjunction with Sass such as Compass, Bourbon, Susy, Bourbon Neat etc. Between that and the fact the Sass syntax – while very similar to LESS – just made more sense to my brain I decided to give Sass a proper try.

That said, there’s really no better or worse choice. They're very similar and are wonderful tools in their own right so just pick one and get started with a more efficient workflow.

What’s the Benefit?

Ah yes, well, here are some of the more obvious and time-saving aspects:

• Promotes reusable code. Write once use everywhere and avoid repetitive typing.
• Efficient maintenance.
• Promotes organization. Think @import without the server requests. See below.
• Can be used with external frameworks and libraries like Compass and Bourbon among others for extended functionality.
• There are several apps such as CodeKit ($29) and Prepros (free & paid) which make compiling a breeze (no command-line).
• Easy to convert an existing style sheet. Change a little at a time or all at once.

Organizing with @import

Breaking up large and/or complex style sheets into smaller, logical files is an effective method of organization. Using the non-preprocessor method it’s accomplished either by calling each file separately in the document head tag, just as you would with any style sheet. For example:

link rel="stylesheet" media="screen" href="css/fonts.css"
link rel="stylesheet" media="screen" href="css/blog.css"
link rel="stylesheet" media="screen" href="css/menu.css"

Or by using @import calls in the main style sheet, e.g., global.css to “import” the child files into the parent ’sheet. For example:

@import url('/css/fonts.css') screen;
@import url('/css/blog.css') screen;
@import url('/css/menus.css') screen;

The problem with both methods is each file or @import call requires a separate server request which can slow load time, create server stress and possibly affect SEO. Does it work? Yes, though it’s not ideal.

A Much Better Way

If using a preprocessor you can import the “partial” (or child) ’sheets into the parent, e.g., global.scss (notice the scss extension). This is very similar to the second example above but with a crucial difference.

@import "fonts";
@import "blog";
@import "menus";

With this approach there’s no performance hit because instead of the server having to process multiple requests all the individual CSS (partial) files get merged with the main ’sheet locally when compiling, long before it’s uploaded to the live server. It is quite simply a perfect solution. Throw in some minifying and You-Are-Golden.

Converting Style Sheets

You can use the import technique with vanilla CSS or mix-n-match with Sass. Meaning you do not need to convert your entire existing style sheet(s) to the Sass syntax. Of course continuing to use CSS would be missing the point of a preprocessor, but it nevertheless makes it very easy to enjoy some of the benefits immediately while learning your way around.

The first step to using your existing style sheet(s) in a Sass workflow is changing the file extension from .css to .scss and ensuring the actual “partial” files you’re importing into the parent ’sheet are prefixed with an underscore “_”. For example:

_fonts.scss
_blog.scss
_menus.scss

Then add as many @import calls as you like to the parent style sheet, e.g. global.scss, and place them where needed within the cascade of “normal” CSS selectors. There’s no default placement or order for partials. Here’s an example:

@import "fonts";
code,
pre {
    border: none; background: #fff;
    font-family: Inconsolata, Monaco; @include font-size(13);
    white-space: normal;
}
p {
    @include hyphens(auto);
    margin-bottom: 1.2em;
}
a:hover {
    font-size: 1.2rem;
}
@import "blog";
#qreativStyle {
    padding-bottom: 20%;
    background: -webkit-linear-gradient(#a6e77e 0%, #72ac4e 100%);
}
@import "menus";

Hands-Free Compiling

Now that you’ve switched your ’sheets from .css to .scss you need a way to compile the Sass files into a single CSS file the browser can use. You have 2 options:

• Use a 3rd Party app like those mentioned above which come prebundled with compilers for most of the popular preprocessors. This is the easiest.
• Or if you prefer the command-line, manually install the Sass distribution and compile your code from the Terminal.

Apps like CodeKit and Prepros will “watch” your project files and automatically compile them each time you save your changes. It doesn’t get any more hands-off.

Conversely, manual compiling means learning the command-line. It isn’t difficult and there are numerous well-written resources that go into painstaking detail explaining the individual commands.

Compass Framework

This is a completely independent (optional) open source CSS Authoring Framework that uses Sass. Think of it as Sass on steroids.

Compass is comprehensive enough to warrant its own write-up but for now I can say that it shines in a project management context and offers a huge range of tools for some amazing functionality. One possible downside is that due to its comprehensive feature-set it might be overkill. I like it but for much of my work I find Sass to be all I need. Still, it’s worth investigating if only to see what’s possible.

Is a Preprocessor Necessary?

Nope. Not at all. A preprocessor is simply a tool to help you write and manage CSS more efficiently. It’s important to understand that while a preprocessor can speed development, it’s not a substitute for learning ‘raw’ CSS. Nor will it fix lazy coding habits.

I admit I underestimated its usefulness initially. If you write your own CSS you know how quickly code piles up so wouldn’t it be nice if you could write less of it but accomplish more? Of course it would. Now you may be thinking, “Do I really want to learn another language?”. The answer should be, “Yes!”. Learning the syntax requires a surprisingly small investment of time for what is a modern and efficient workflow.

Are preprocessors the latest Flavor-of-the-Month? Who knows, but I rather doubt it. There’s no question they offer time-saving benefits but only you can decide whether that’s enough to entice you to try one. If you're interested in learning more I like this article by Chris Coyier: Sass vs. LESS.