A few months ago (early 2013), I finally started dabbling with Sass and since incorporating it into my workflow, I cant think of why I would want to work on a new project where I couldn’t use this preprocessor.

Sass has helped me write leaner, more organized CSS, without significantly bloating my file size and including imports that would slow down my page loads.

But let’s back up for a second real quick.

What is Sass?

Sass is an extension on normal CSS syntax. It adds the ability for creating variables, nested rules, repeatable code snippets called “mixins” and many more functions. At the time of writing this article, I am still poking around at some of Sass’s more indepth features, such as Control Directives and creating custom Sass functions.

As for my work flow, I take an OOCSS approach when building my web projects. I like my rulesets to be small and modular, cutting down on as much redundancy as possible. SASS helps out with these goals tremendously.


As I mentioned, one can make use of variables in Sass, which allows for a streamlined approach to writing various CSS values. Have a particular shade of yellow that is used throughout a project? By creating a variable:

$banana: #ff0;

you can now write your color rule as:

.my-Class {color:$banana;}

Using variables is quite handy when a request comes down to change said color. Now instead of having to do a find and replace through your document(s), a simple change of $my-Color will auto update all the instances of that variable throughout your stylesheet.


Mixins are another way to significantly reduce the amount of redundant code in your stylesheets, keeping them nice and orderly for production, and including all the necessary bits when compiled for deployment.

One of the most used examples of mixins are to simplify the writing of vendor prefixes.

A basic box-shadow class:

.my-box-shadow {
  -moz-box-shadow: 0 5px 10px rgba(0,0,0,.8);
  -webkit-box-shadow: 0 5px 10px rgba(0,0,0,.8);
  box-shadow: 0 5px 10px rgba(0,0,0,.8);

Not too bad if you are only using this one box-shadow class, and this one variation of shadow. However, writing this over and over again throughout your stylesheet is just kind of tedious, and prone to error if anything were to change.

By creating a mixin for box shadows

@mixin box-shadow ($value...){
   -moz-box-shadow: $value;
   -webkit-box-shadow: $value;
   box-shadow: $value;

the above class, and any further uses of the box-class rule can be written as such:

@include box-shadow (0 5px 10px rgba(0,0,0,.8);

Mixing variables and mixins together can make writing rules even easier with simpler maintainability.

Let’s use the above box-shadow mixin and use a variable in place of the value we entered. Yes, a string can be made into a variable.

So our new variable:

$batman: 0 5px 10px rgba(0,0,0,.8);

in combination with our mixin makes:

@include box-shadow($batman);

Much simpler eh?

Another great thing about Mixins is that if you don’t use them in your main Sass files, they won’t compile into your outputted CSS. So you can create a nice library of Mixins, or include libraries like Compass, and if you only use a fraction of the Mixins, only that fraction gets exported to your final CSS. Much leaner than using many other CSS frameworks, that are great in their own right, but usually contain tons of extra bloat code that you likely don’t need for smaller projects.

One of my favorite parts of Sass is the ability to separate out files into smaller code chunks, and then import them all together via a master Sass file. Prior to using Sass, I would section off areas of my CSS file with a few lines of comments, designating where the beginning and ending of a particular section of my website was styled. Such as:



*     Header Area



I would do this for most main sections of the site, including my normalizing/resety CSS at the top, and working my way down to the Media Queries and IE specific classes at the bottom of the file. This system worked well for me, but would make for dauntingly large CSS files and sometimes I’d find myself hard pressed on where to place certain rules.

I have a three column call out for my home page, but also on a few internal pages. It’s the same rules I use, with a helper class to extend the base three columns. Do I split up the code into a home page section and then the helper class into the internal page section, or keep it all together?

With Sass, I can organize my code by area, module, mixins, etc. Using @import, I can link Sass files together, and in the end they all compile into a single file.

Here’s a snippet from one of my master files to showcase how I pull in my various Sass files.

// Variables and Mixins
@import '_project-sass/project-Vars';   
@import '_base-sass/mixins';

// Base HTML Values
@import '_base-sass/base';  
@import '_base-sass/layout';
@import '_base-sass/tables';

// Interactions
@import '_base-sass/navs';
@import '_base-sass/buttons';
@import '_base-sass/forms';

// Branding & Typography
@import '_project-sass/project-Type';
@import '_project-sass/project-Base';

And each of the above files may have their own subset of imports to break down those files into more manageable pieces.

One final topic I’d like to cover is nested elements and selectors in Sass. While in normal CSS, one might write their selectors as:

.nav { padding: 0; }
.nav li { float: left; }
.nav a { text-decoration: none; }
.nav a:hover, .nav a:focus { text-decoration: underline; }

Sass helps reduce the amount of repetitive code by letting you nest these selectors together:

.nav {
  padding: 0;

  li { float: left; }   

  a { 
    text-decoration: none;
    &:focus { text-decoration: underline; }

You’ll notice that I kept my nesting as shallow as possible. I’ve seen some people write their Sass like:

.header {
  .nav {
    li {
      a {  }

Which would output as

.header .nav li a {...}

This isn’t an egregious example, but it’s unnecessary to be overly specific. When .nav a{} would suffice.

Getting started with Sass is not as difficult as one might think. If you’re comfortable with the command line, Sass can be installed with a few short commands and start watching your directories to auto-compile your files. Check out https://sass-lang.com/download.html.

If you are wary of the command line, there are a bunch of really great apps out there that make working with Sass a breeze.

Also be sure to check out The Sass Way for a great collection of guides on how to get started with using Sass, and best practices to make sure you’re using optimizing your work flow and producing great code.