The Sass Switch

I’ve been hearing about CSS preprocessors for a while now. Yet, I’ve never taken the time to actually learn one. Spurred on by Alex Ilhan’s new email framework, Zenith, which uses Sass to write styles, I thought it was time to dig into Sass and figure out just what was going on.

We all know that writing and maintaining CSS is typically a cumbersome process. Fortunately, a few preprocessors have been making that task more manageable and even fun these past few years. Sass, created by Hampton Catlin, is one such preprocessor. Sass allows you to use things like variables, reusable mixins, expressions, and functions to make building websites easier. It’s insanely powerful.

After hearing about Alex’s success with using Sass in email, I knew I had test things out. And, being a huge fan of anything published by A Book Apart, I figured a great first step would be to order Sass for Web Designers by Dan Cederholm. It proved to be the perfect introduction to the topic. Although a very quick read (they are, after all, brief books for people who make websites©), it went over the essential features of Sass and, more importantly, gave fantastic examples of how to actually put it to use.

Feeling dangerous with my newfound knowledge, I set about refreshing my website. Website redesigns come quick around here, as I find them to be an excellent way to learn and apply a new skill. Apart from the visual overhaul of my site, I wanted to accomplish the following:

  • Use CodeKit
  • Use Sass to generate all my CSS
  • Learn about variables
  • Learn about mixins
  • Learn about nesting

Using CodeKit

A while back, I picked up CodeKit from Incident 57. CodeKit is an amazing tool to streamline web development. It allows you to compile pretty much anything, auto-refresh browsers, install a ton of tools via Bower, and even optimize assets. While I have barely touched the surface of what’s possible with CodeKit, it was a huge help when it came to just using Sass.

I created my project and started up CodeKit, telling it to watch the project. It automatically knows to watch for SCSS files and compile them. The only two things I had to adjust were disabling compiling Markdown files and the build path of my Sass files. Since I use Statamic as a CMS, all of my content lives in Markdown files. Initially, anytime I edited Markdown and saved it, CodeKit would compile it into a corresponding HTML file in the same directory. Disabling this was as easy as adding the .md extension to a list of files to ignore in CodeKit.

Ignoring Markdown

CodeKit automatically compiles Sass into CSS and dumps it into the same directory. However, I wanted to maintain the typical Statamic theme structure, so I had to adjust where it output files. This was easy enough in the project settings panel. In the same vein, I was using import so that I could separate my Sass files and bring them together later on, so I had to disable compilation for my included files. Again, all it took was a simple checkbox.

Disabling Compilation

With everything ready to go, it was time to structure my Sass files.

Sass Project Structure

My project structure is fairly simple. Within my sass directory, I have files for Normalize, my variables, mixins, and structure, which are all brought together into the main theme file, kundera.scss. All of them are compiled into my css directory as kundera.css. It’s nice to have all of that included in one call to the server. In Statamic, my theme directory looks like this:


While I love the idea of keeping concerns separated in CSS, it seemed like overkill for this project. My CSS is always minimal, so my variable and mixin files ended up being sparse. However, it seemed like the way to go to get used to how modern applications are structured, as well as making sure I’m importing things correctly.

Using Variables

Variables are fucking amazing. Even if Sass didn’t do anything else, I’d still use it just for variables. Being able to change one line of code instead of a dozen is fantastic. I don’t think there’s any way I’m going back to writing vanilla CSS, unless forced. Again, my website is extremely simple. Here’s what the variables.scss looks like:

// Colors
$white: #fff;
$light-grey: #F5F7FA;
$dark-grey: #434A54;
$red: #FC6E51;

// Font Stack
$body-text: 'Open Sans', sans-serif;

// Breakpoints
$small: 500px;
$medium: 800px;
$large: 1200px;

There’s nothing special, but being able to use these throughout my styles was magical. The real beauty came with using functions to manipulate those variables. For example, the hover state of my text links used darken to change colors. It’s awesome:

a {
    color: $red;
    text-decoration: none;
    @include text-link-hover;

    &:hover {
        color: darken( $red, 20% );

You may notice that @include line. Let’s talk about mixins.

Using Mixins

Mixins are another magical feature of Sass. Mixins allow you to define blocks of styles and use them throughout—saving you a lot of time in the process. Mixins are especially useful when it comes to dealing with CSS3 and vendor prefixes. For this project, I only had two mixins:

// Transitions
@mixin text-link-hover {
    -webkit-transition: all 0.4s ease;
    -moz-transition: all 0.4s ease;
    -o-transition: all 0.4s ease;
    transition: all 0.4s ease;

// Visuals
@mixin rounded($radius) {
    -webkit-border-radius: $radius;
    -moz-border-radius: $radius;
    border-radius: $radius;

The rounded mixin is cool in that you can pass it a value to determine how much you want to round corners. So, for my images and buttons, I called the rounded mixin like so:

article img {
    @extend img;
    @include rounded(4px);
    display: block;
    margin: 2em auto;

You can also see that I extended my img selector, another wonderful Sass feature. Mixins are very powerful. You can set them up for nearly anything you want. Later on in Sass for Web Designers, Dan Cederholm does some fancy tricks with mixins and media queries. Very cool.

Nesting Rules

The last feature that I used (although nowhere near the last feature Sass offers) was nesting rules. Nesting rules is handy for keeping your code organized and readable. By nesting rules, you no longer need to repeat selectors, which not only keeps your code DRY, but makes maintenance a hell of a lot easier.

For example, instead of writing something like this for my navigation:

#nav {  }
#nav a {  }
#nav a:hover {  }
#nav a.on {  }

I can instead nest rules:

#nav {
    float: right;
    padding-top: 8px;

    a {
        display: inline-block;
        margin-left: 22px;
        color: $dark-grey;

        &:hover {
            color: $red;

        &.on {
            color: darken( $light-grey, 10% );

It takes a bit of getting used to, but makes perfect sense when you actually start using it.

Some Other Goodies

I had a hell of a lot of fun with Sass, and I barely scratched the surface. I can’t wait to put it to work on some more projects, as well as set up a workflow for building HTML email with it.

Apart from learning Sass, I had two other goals for the website redesign. The first was to add a new section called Asides. Asides will function like a blog, but will contain very quick thoughts and links to cool stuff I find around the web. It’s a dumping ground for anything that doesn’t necessarily warrant a full blog post. I’ll likely post a ton of illustrations and GIFs in there, too.

The second goal was to add the ability to art-direct blog posts. I’ve always admired people like Trent Walton and Jason Santa Maria, not only for their amazing writing, but also the manner in which it is presented. I’ve lusted after the ability to style individual posts to fit the content, and now I have it.

Using Statamic, I now have some YAML front matter to style posts and inject those styles into an article. I’m working on my first one and can’t wait to show it off.

All-in-all, this was a fun redesign. I’m fairly happy with the end result and loved learning about Sass. While things are always likely to change around here (after all, this is my playground), I think I’ve built a solid foundation for growing my site.