Sass: A Designer’s Perspective

Let me start by saying that I am not a developer. Sure, I can write some pretty solid HTML and CSS, but beyond that I defer to our great team of developers. So when I first heard about Sass, the right side of my brain freaked out. While the idea of Syntactially Awesome Stylesheets sounds pretty cool, I was afraid that Sass was going to make writing CSS more like programming Ruby, PHP, or Javascript. If you've been scared away from using Sass for the same reason, I'm here to tell you that nothing could be farther from the truth. Sass actually gives us some really powerful ways of writing CSS more efficiently.

If you're looking for a tutorial on getting started with Sass, this isn't it. You can find everything that you need to get rolling on the official Sass tutorial. This post is also less technical and more about my experience, some lessons learned, and a few tips from an actual project. I'll be referring exclusively to Sass 3, the latest syntax that is also known as SCSS. This new syntax uses semicolons and brackets to specify blocks of code, so any standard CSS file is already a valid Sass file. (You're feeling better already, aren't you?)

It's important to note that Sass isn't going to be the best fit for every project by default. Sites with a lot of pages or application-based sites tend to be well suited for using it. These types of sites generally allow you to take full advantage of the efficiencies that are provided, like variables and mixins. It would be unnecessary overkill to set up Sass for smaller sites with fewer pages or less-common elements.

Now let's get on with the details, starting with some tips and techniques that I found to be helpful.

Use Variables and Mixins ... a Lot

One of my major complaints with CSS has been that I can't create variables for the common properties that are used heavily. Sass variables work just as you would expect. They are particularly helpful for defining properties like colors, font families, and common widths and heights that are broadly used throughout your CSS. You can enhance their power by using operations.

As much as I love the variables feature, Sass really grabbed my attention with mixins. Mixins are even more powerful than variables, allowing you to reuse entire chunks of CSS. If you're familiar with using HTML includes, you can think of it as creating includes for your CSS. For example, you might have a particular button style that is used throughout your site. The positioning or size of the button may change depending on where it is placed. The mixin below sets the colors and padding for the button, but leaves other properties like positioning to be defined by another mixin, class, or id.

@mixin blue-button {<br /> @include gradient (#5eb9d8, #2795ba);<br /> color: #fff;<br /> padding: 3px 10px;<br /> border: 1px solid #0c87b1;<br /> &:visited {<br /> color: #fff;}<br /> &:hover {<br /> @include gradient (#449bb8, #1f6b83);<br /> border: 1px solid #0b6482; <br /> color: #fff;<br /> }<br /> }

You may notice the "@include gradient (#5eb9d8, #2795ba);" on the first line of the mixin. That is another mixin defining a commonly used gradient style being pulled into the mixin that we're creating. Mixins mixin' with mixins? Amazing, I know! Try to contain your excitement. But the next time that you need this button style, it would be so much faster to write this:

.my-spiffy-blue-button {<br /> @include blue-button;<br /> font-size: $default_fsize;<br />}

Syntactically awesome! This is only the tip of the iceberg of what you can do with mixins and variables. I encourage you to dig into the documentation to get the most out of them.

Separate Your Stylesheets

Okay, I know what you're thinking. "Are you kidding? I do this already. I'm skipping ahead. Is it lunch time yet?" Just hold on. I'll admit that this is a pretty simple idea, but it's a powerful one when working with Sass.

On a recent project I created individual stylesheets for each major section, just as I might on a larger site using regular CSS. Soon I was up to 16 ... 17 ... 18 stylesheets and counting. My original intent of keeping my CSS simple and organized was actually causing more confusion with all of this segmentation. Rethinking the entire methodology, I started grouping styles based on their purpose rather than their location. So it looked a little something like this:

Some of the groupings are self-explanatory, but others require a little more description. Here are three stylesheets that are of particular note:

variables.scss

Grouping all of the variables together and loading this stylesheet above the others will allow you to use the variables in all of your stylesheets.

mixins.scss

Having a central repository of these CSS chunks makes it easy to quickly create and combine new mixins and reference them as you build out your CSS. On a larger site this is a task that you'll find yourself doing often.

modules.scss

Modules are those classes that you can apply to any number of tags in your HTML to avoid bloated code. These don't have anything to do with Sass, but check out Nicole Sullivan's OOCSS to learn more.

Additional stylesheets -- including basic.scss, forms.scss, and structure.scss -- were all separated into individual stylesheets because their functions on my project were very specific. Your project may be different, but the idea of grouping styles by purpose is key. After revisiting the code from the original fifteen section-specific stylesheets, I was able to simplify them significantly with Sass to fit manageably into a single stylesheet called sections.scss. There was much rejoicing.

Nested Rules

One of the simple yet powerful features that Sass offers is the ability to nest styles. This was far more difficult for me (a non-developer) before the latest version of Sass was released. The previous syntax used indentation to associate blocks of code. To me it felt a bit awkward and unfinished, like something was needed to finish the block of code.

Thanks to the latest version of Sass, the brackets and semicolons that we're used to seeing in CSS are back. But because we're not used to nesting styles, doing so without using indents is also visually overwhelming and difficult to follow. Making good use of indentation can have a profound impact on the readability of your CSS.

One final note on nesting -- it's easy to get caught in the trap of targeting a specific HTML tag like this: 

#sassy-id-name #wrapper ul li {<br /> color: #000;<br /> }

With Sass, it's better to nest everything from the start, like this:

#sassy-id-name {<br /> #wrapper {<br /> ul {<br /> li {<br /> color:#000;<br /> }<br /> }<br /> }<br /> }

Why does this make sense? It's simple really. Let's say that you decide to add a new container within #sassy-id-name, and you need to target it specifically. It's much easier and more concise to simply add the new rule within the existing nested group, rather than creating a completely new ruleset. So it might look like this: 

#sassy-id-name {<br /> <strong> #new-container {<br /> color: #333;<br /> }</strong><br /> #wrapper {<br /> ul {<br /> li {<br /> color:#000;<br /> }<br /> }<br /> }<br /> }

These are just a few of the things that I learned along the way while trying Sass for the first time. I know that I've only touched the tip of the iceberg with what can be done, so please share your ideas and tips below.