Development

I love me some Sass

About two months ago, I finally started dabbling with it and since incorporating Sass into my workflow, I honestly don’t think 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 than I ever thought possible, without significantly bloating my file and including imports that would slow down my page loads.

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

What is Sass?

For those that don’t know, 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 just shy of two months of working with Sass.  I haven’t even gotten into some of the more interesting aspects of the extension, such as Control Directives and creating custom Sass functions.

As for my workflow, I take an OOCSS approach when building my web projects.  I like everything to be as small and modular as possible for maximum reusability as well as to cut down on redundancy.  SASS helps out with these goals tremendously.  

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:

you can now write your color rule as:

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:

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

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

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:

in combination with our mixin makes:

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 files.  So you can create a nice library of Mixins, or include great libraries like Compass, and if you only use a fraction of the Mixins, only that fraction gets exported to your final CSS.  Much nicer 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:

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.

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 & selectors in Sass.  While in normal CSS, one might write their selectors as:

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

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

Which would output as

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 http://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.  Check out the Compass App or Mixture.  I personally love the Mixture app and use it to start up all my projects.

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 workflow and producing great code.

  • Thomas Palumbo

    Great article. I’ve used most of these except the separating of files. That’s such a great feature!

Subscribe to our mailing list