I’ve been discussing Sass, the CSS pre-processor, with a few fine folk over the past couple of days, particularly the “should I use it?” angle. Here’s how I got started, and why I stuck with it. The short version is: it helps me write more readable and understandable CSS.
I decided to make one change at a time to my normal CSS workflow, over the course of a couple of weeks. I chose Sass over Less or Stylus (other CSS pre-processors) because it looked a bit friendlier and there were more resources for help available, based on some quick googling.
Compile a simple CSS file
The first thing I did was to rename my style.css to style.scss and get that to compile. No using of any Sass features: just seeing if I could make a CSS file from a Sass one. (What did I use to do this? See practical concerns below).
Variables
The next thing I looked at was using variables. Rather than having hex codes like #6B0000 scattered throughout my code, I had $primary-colour and $secondary-color. This made the CSS more readable, and made it start to feel more like “real” code: variables and things!
Nesting
Next up was nesting. If you’re styling a link in a navigation list, you might write a CSS selector like this: nav ul li a { /* styles */ }. Sass lets you write those selectors inside each other for much better readability.
I try and write CSS in a SMACSS style, so I wanted to avoid that kind of deep nesting, and using of specific HTML patterns. Something like .nav-main a is kind of okay, so I used nesting there a lot.
What I did find really useful was being able to nest media queries. Rather than having many media queries throughout my CSS, and I could keep all the changes over screen sizes for a particular element in one place. Here’s a short example:
The css:
h1 {
font-size: 2em;
}
@media (min-width: 30em) {
h1 {
font-size: 2.5em;
}
}
@media (min-width: 60em) {
h1 {
font-size: 3em;
}
}The sass:
h1 {
font-size: 2em;
@media (min-width: 30em) {
font-size: 2.5em;
}
@media (min-width: 60em) {
font-size: 3em;
}
}Shorter and, for me, much more readable.
Partials
The next change I made was to use partials. Regular CSS lets you use @import to pull in another file. This is not great because it means another file to download. Sass does the cunning thing of letting use you @imports to pull in files, but it does that as it compiles, meaning you still end up with one CSS file at the end.
I want to split my CSS rules into base, layout, normalise, typography, and other categories, to make the code easier to read. Rather than have one long CSS file with comments to split it into logical pieces, I have separate small Sass files: much easier to find existing stuff and know where to put new stuff. Sass let me do that using partials: start a Sass file name with an underscore, and it won’t get generated into a CSS file; use @imports to include the partials in my style.css.
Practical concerns
When I was getting started with Sass, I found the command line scary. Actually, I still find it scary now, even though I use it every day! At the moment I’m using GulpJS (a JavaScript task runner: write little bits of JavaScript that let you automate things like compiling sass (and a whole bunch more)) or building things with Jekyll (a static site generator that handles Sass compilation for you), but for a long time I used CodeKit, and I still highly recommend it. It does many awesome things.
But wait, there’s more
These days I'm looking at fancier stuff too. There's mixins for having little functions, @extend for grouping of things (although now it seems that maybe @extend isn’t so great), and susy for easier grids.
Summary
I find writing Sass easier and more fun than writing straight up CSS. I got into it by changing one thing at a time, and learning Sass in small chunks: variables, then nesting, then partials. There are many command line tools, and a handful of apps to help get you started.