Getting Sass(y)

May 31, 2012

I finally jumped into the world of CSS preprocessors about 2 months ago. I started using Sass on a refresh of my personal site. Since then, I have used Sass in 2 redesign projects in my work at Bonnier Corporation and really like working with it. I wanted to pass along some tips and advice that I have found helpful.

What is Sass

Sass extends the functionality of CSS by allowing you to use variables, nested rules, selector inheritance, mixins, math, and other goodies. Sass is then translated into plain old CSS for use on your Website.

Sass as a helper function. It allows me to write less code and gives me several functions to streamline my development time. What I really like about Sass is that it does not lock you into a system. You can choose to abandon Sass at any time because Sass is generating plain old CSS files that you can continue to use if you abandon using Sass.

Sass needs a translator to compile it into CSS. Sass is a Ruby gem so Ruby is essential for it’s translation in CSS. Which brings me to my first tip.

Use Scout

Scout is a cross platform app that runs Sass and Compass in a self contained Ruby environment. No need to update your Ruby installation or use command line. With Scout, you can be up and running with Sass in no time.

My biggest barrier to entry into Sass was the fact that I had to update the Ruby installation on my operating system. As I tried to update Ruby on my Mac, I ran into problems trying to install a program that would run Ruby. I got no feedback from the command line as to whether or not the program installed. But when I tried to do some additional configuration, I discovered that the program had not installed. Way too much hassle.

With Scout, I install the app. Use the GUI to set up my new Compass project. And press “play” to tell my computer to watch the Sass files. Just as advertised, Scout is ‘Sass and Compass without all the hassle.’ Scout helped me cross hurdles I had to entry and  jump right into the world of Sass, without the hassle.


When I decided to use Sass, I decided to go the route of using SCSS instead of the SASS syntax. Because the SCSS syntax is the same as CSS, it is a low barrier of entry. This was important because I wanted to encourage the other front end developers on my team to use it.

I also made the choice knowing that I will not be able to use Sass in all my work. I think it would be easier for me to get use to leaving out the brackets and semi-colons in my code if I was using straight up SASS.

Just as simply using <!doctype html> allows someone to start using HTML5, the SCSS format allows someone to get up and running in using Sass. You would simply need to create a new .scss file for a new project, or you could copy your existing CSS files, create a new folder, paste your CSS files, and change the file format to .scss. It is that simple. How much of Sass you use from there is up to you. Pretty easy.


Variables were the most attractive thing to me about using Sass because of it’s practical value. No longer did I need to keep declaring a hex value every time I wanted to declare a color. I could simply set up a variable and use it every time I needed it. I would have consistency in my color values and I could always change the declaration once and have it be updated in my code when the file was processed to CSS.

One way I have used variable is to define my font stacks. I have even created different variables for bold, medium, and italic faces for Web fonts. Using variables means that I define my stack once and then only have to remember the variable name each time I want to call upon it.

I found this incredibly helpful recently when a client decided they wanted to use a serif Web font only for headings and not for the body copy. All I had to do was change the font-family declaration in the variable and I was done. All the headings already were using different variables because of the font weights. I only had to change the variable in one place and let Sass do the rest.

Example of some of my variables:

$sans-serif:'OpenSansRegular', sans-serif;

Extend (Selector inheritance)

Extend was the next thing that I got excited about. When I did a refresh to the design on this site, I wanted to randomize the color scheme. So I needed to declare different styles for the background of the header for each of the colors. I had already written out my styles for the header and needed to apply those same styles to the footer. This is where extend came in handy. I wrote one line of SCSS and Sass did the heavy lifting for me.


#branding {background-color: #000;}
  .blue #branding {background-color: $blue;}
  .red #branding {background-color: $red;}
  .orange #branding {background-color: $orange;}
  .green #branding {background-color: $green;}
  .purple #branding {background-color: $purple;}
#site_info{@extend #branding;color: #fff;}

Compiled to this CSS

#site_info {
  background-color: #000;
.blue #branding,
.blue #site_info {
  background-color: #007298;
.red #branding,
.red #site_info {
  background-color: #be162d;
.orange #branding,
.orange #site_info {
  background-color: #c56819;
.green #branding,
.green #site_info {
  background-color: #198a3d;
.purple #branding,
.purple #site_info {
  background-color: #5f2b6d;
#site_info {
  color: #fff;


If there is a feature of Sass that I have under utilized, it would be mixins. One way that I have used them is for modular content. Another thing I am learning about and applying in my work is the idea of scalable and modular architecture (SMACSS). I plan to write a separate post about that in the near future.

One of the ideas of behind this approach is to recognize reusable components or modules in your site and then use classes to apply CSS to those components. This allows you to keep your CSS simple and maintainable by writing one declaration and then using classes in your HTML markup that will match.

On one site I was working on recently, it was not possible to add classes to the HTML. So instead, I created a mixin and applied that to different elements in my CSS. It involves more code in the CSS file but it still meets the objective of creating a more maintainable code for the developer in the SCSS file.

Here is an example of one of my mixins. It is for list items that will display horizontally, like an image gallery, horizontal navigation ,etc.

@mixin horizontal-listing($margin) {
  li {
  li:first-child {


When I started out with Sass, this was the one feature I did not think I would use. I am not sure why. Maybe I did not see a lot of value gained from it. Boy was I wrong.

Once I started using nesting, I really liked it. It is really nice to be able to write less code and visually to see the relationship of the child elements.

One word of advice. I have ended up with a couple of really long nested declarations. I have considered going back and breaking them up, mostly to increase the maintainability of the code. One strategy would be to put in comments to remind yourself or another developer of what the parent selector is and even to write out fully in the comments what the selector will be in your compiled CSS file.


There is a lot of things that Compass does. But I only use one part of it, CSS3 mixins. No longer to I have to write out all the browser prefixes but Compass includes these mixins to make my life easier and my code more maintainable.

What I like about Compass is that it is modular so I can choose the components of it that I want to use and can ignore the rest. It does not add additional load to my CSS files but works behind the scenes just like Sass to help improve my workflow.

Here is an example of a CSS mixin in action:

@import “compass/css3”;
.element {
  @include border-radius(25px);

Compiles to:

.element {
  -webkit-border-radius: 25px;
  -moz-border-radius: 25px;
  -ms-border-radius: 25px;
  -o-border-radius: 25px;
  border-radius: 25px;

Why I Chose Sass?

One question I might get is why did I choose Sass over LESS. As I weighed my options, I felt like Sass was a better direction to go. Chris Coyier did a great write up on CSS Tricks recently comparing Sass to LESS. I will warn you that his conclusion is that Sass is the better option.


I am a resource matchmaker. I enjoy being able to connect people to the resources they need to be successful. That is the reason I post on this blog.

Here are my recommendations:

  • Chris Coyier’s post on Sass vs. LESS
  • Sass Reference – This where I learned most of what I know
  • Compass Documentation
  • Pragmatic Guide to Sass – Short little book that filled in some of the gaps in my Sass knowledge. Also includes a section on Compass. I learned most of what I know about Compass through this book.
  • Just build something! – This is a mantra from Chris Coyier that he oftens says on Shop Talk Show. The best way to really learn something is to use it. As I mentioned, I got my feet wet in a personal project. Then I looked for more projects to keep practicing and expanding my knowledge and skills.
  • Shop Talk Show – Although this is not a specific Sass resource, this podcast is a great for Web designers and front end developers. Each week, Chris Coyier and Dave Rupert talk shop by answering listener’s questions. Most weeks they feature a special guest. Jina Bolton was their guest early on and there was a lot of discussion about Sass.
  • The Sass Way – A friend of mine suggested that I add this to the resource list. He found the beginner tutorials helpful. I have also read several articles on the site since I originally wrote this post.

1 Comment

  1. Frank

    July 18th, 2012

    Lots of in-depth detail here Jeff— big thanks. I know this will help many new comers to SASS tremendously. A resource I found useful as I began down my own sassy ways was — At the time, it was the only true source for documentation and technique. Sure it will help others even post SASS’s tipping point.