Getting more out of SASS

Getting more out of SASS

Chris Peak
Chris Peak

October 12, 2012

SASS (Syntactically Awesome Style Sheets) is a powerful extension to CSS that allows you to use variables, nested styles, mixins and more, but for someone who is used to vanilla CSS, getting started with SASS can be a little daunting. I wanted to share a few tricks that I use in most of my projects so you can get more from SASS.

Colors

Using SASS instead of CSS lets us set, saturate/desaturate, change opacity, and even change colors to grayscale. Let's say our branding includes a nice deep ocean blue - since we are using SASS we set this at $brand-color: #336699;. By doing it this way if we choose to update our branding in the future we don't have to hunt down each instance where we used that color in our design.

Here are some options for adjusting the brand-color in our example, and the resulting hex codes.

posts/2012-10-12-getting-more-from-sass/colors.gif

Avoid unnecessary duplication

Recently I started work on refactoring a client's existing codebase. Diving into the code I realized that they had manually defined background-gradients for each occurrence. Until it is supported as an official CSS3 spec we are forced to use vendor tags to insure cross-browser compatibility. This means that every time they used a gradient on the site they defined it using at least 7 lines of CSS. I found at least 6 instances like this in the code base, adding up to over 40 lines of code. Using variables and includes in SASS I defined the background-gradient once, acting like a color-agnostic function and then calling it using an include with variables. Here is the definition block:

posts/2012-10-12-getting-more-from-sass/mixin-gradient.gif

and here is a simple example class. Instead of repeating the full block, I simply use an @include with the colors I want to use in this instance:

posts/2012-10-12-getting-more-from-sass/include-gradient.gif

Toggle Debug mode using a Boolean

When working on a complex site with a lot of database interaction or when I need to see data in views that I don't want in production I find it very useful to have debug options in the development build. One way to achieve this is to use SASS booleans to show or hide debugger output. I like having one line at the top of my CSS to toggle output on/off so I don't have to dig through code looking for specific divs.

Using a @mixin called debug_display, I tell it to check the boolean $debug. A simple if/else statement tells the .debug_window to either display: normal; or display: none; This is a simplified example, but it is very handy with multiple divs containing debug information in different places.

posts/2012-10-12-getting-more-from-sass/debug.gif

Better semantics using Extends

A major hurdle in programming is keeping your code semantic while keeping it readable to other developers. One trend for laying out divs is to use stack or chain classes in your HTML, but I find that unless you are very disciplined things can get unruly very quickly.

A simple example would be a moveable sidebar class. Before we could define it in HTML as <div class="sidebar l_right">..., but that is not the most semantic nor the most readable way. A better option is to use SASS @mixins:

posts/2012-10-12-getting-more-from-sass/sidebar.gif

By defining the bulk of the .sidebar class and using 2 extensions for floating it left or right, we make it easy for a developer or another designer looking at the HTML to switch the sidebar position without tracking down the original CSS definition.

To be continued...

In the next post we will take a closer look at SASS operations and how that can help us when developing a fluid grid based design.