I love me some Sass

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 without it.

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

But let’s quicly back up for a second.

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 post, I am still poking around at more of Sass’s features, such as Control Directives and creating custom Sass functions.

Variables

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

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 a 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-shadow rule can be written as follows:

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

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

Let’s use the previous 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.

Another great thing about mixins is that if you don’t use them in your main Sass files, they won’t compile into your compiled CSS. You can create a nice library of mixins, or include libraries like Compass. If you only use a fraction of the mixins, only what you use 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.

File Separation

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 spending too much tie wondering where to place certain rules.

For example, say I have a three column call out for my home page, but that is also used 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;

  ul { list-style: none; padding: 0; }

  li { display: inline-block; }   

  a { 
    &:hover,
    &:focus { 
      outline: 2px solid;
      outline-offset: 2px;
      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.

Try it out

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 sass-lang.com.

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.