June 1, 2012
The #1 Reason to Use Sass
Once upon a time, many CSS experts sang the praises of multiple stylesheets: put your layout rules in one stylesheet, your typography in another, your form rules in yet another. This organizing technique provides a way to handle large amounts of styles, simplifies finding the ones you need to edit, and makes it easy to identify where to place new styles. However, since that time we’ve learned that multiple server requests are a major performance bottle-neck; the fewer requests a web page needs to make, the faster the site performs. Now the rule-of-thumb is to put all of your styles in a single, external stylesheet.
It seems we need to make the tradeoff between our needs as web designers and those of our sites’ visitors. Fortunately, thanks to Sass we can have the best of both worlds: multiple, smaller, modular files for development, and a single stylesheet for production.
If you’ve stuck your toe in the pool of CSS pre-processors like Sass, LESS and Stylus, you may have found the water too cold for your liking. The programming language features of pre-processors can be intimidating, and the learning curve for mastering a pre-processor language can feel very steep (even for seasoned web designers).
Fortunately, you can benefit from Sass without digging deep into the Sass syntax. Because Sass is a superset of CSS3, you can write straight-up CSS in a Sass file. In fact, you can compose an entire file with just CSS, and that’s OK with Sass. The only Sass command you’ll need to learn is the @import directive. This command lets you import another Sass file into the current file:
Because CSS pre-processors “compile” their code into a single .css file, you can import multiple Sass files (each with its own set of CSS rules) into a single, production-ready .css file. Here’s my approach.
- Create individual Sass files for each collection of styles.For example, you might have one file with your CSS reset rules, another with a grid system, a third with typography, a fourth with forms, and so on. Sass files end in .scss, and you should pre-pend the file names with an underscore. For example, you might have files like this:
The underscore indicates that the file should be imported into another Sass file. These files don’t need to include any Sass syntax whatsoever — you can treat these like plain .css files and write your CSS rules as you normally would in them.
- In the same directory you placed the other .scss files, create a main Sass file. This file can be named anything you like but styles.scss is good.
- In the main Sass file — styles.scss, for example — add @import directives for each file you wish to include:
SASS lets you leave off the _ at the beginning of the name and the .scss at the end.
- Compile the main Sass file. How you do this will really depend on how you set up Sass. Sass comes from the Ruby programming world, and as such, isn’t really geared to designers. In it’s most basic form you use command line tools to install and use SASS. Fortunately, there are GUI tools you can use: CodeKit for the Mac is awesome. It’s the tool I use and it works well. LiveReload is another tool which works on Macs (and has an early Windows beta version out as well.) (If you know of other GUI tools for Sass, let me know in the comments).When you compile the main Sass file, Sass combines all of the individual .scss files into one .css file for your site. Even better, you can instruct Sass to output a “compressed” version of the CSS. This is kind of like a “minified” version — comments are stripped out, extra spaces removed, and colors are reduce to their shortest representation (for example, #000000 is turned into #000). This feature is fantastic: it lets you load up your individual .scss files with all the comments you want, providing detailed instructions for every rule if you’re so inclined, but then output a small, comment-free CSS file for production.
The hardest part of this whole setup is getting Sass up and running on your system. That’s why, if you’re on a Mac, just pony up the money and buy CodeKit. You can have this whole system up and running in a matter of minutes; you can skip all the actual Sass code (except for the @import directive), and reap the benefits of well-organized, easy-to-read, highly commented code during development, and optimized CSS for deployment.