At this year’s CSS Summit (hosted by the awesome folks at Environments for Humans) there was a lot of chatter about Cederholm’s upcoming A Book Apart release Sass For Web Designers. I, for one, am super excited to read it. I was also really excited to hear Cederholm talk about how he got started with Sass in an interview given during the summit.
Coincidentally, his approach to getting started with Sass was identical to mine. I imagine it’s the same approach most people take. So common, and so simple, that I think it’s worth putting in writing for anyone who’s still hesitant about giving it a try. Getting started with Sass really is as easy as one, two, three.
Step One
Take any CSS file and replace common values with variables.
Let’s say, for example, we’ve written the following CSS for our heading tags.
h1 {
font-family: "CallunaRegular",serif;
font-size: 150%;
line-height: 1.5;
color: #5a5a5a;
}
h2 {
font-family: "CallunaRegular",serif;
font-size: 100%;
line-height: 1;
color: #5a5a5a;
}
Each tag has four properties, font-family, font-size, line-height and color, with similar, if not identical, values across both tags. Turning these values into Sass variables will allow us to more easily maintain these rules and reduce the amount of time it’ll take us to make global changes to our stylesheet.
First, let’s define our variables. We’ll do this outside of the h1 and h2 rules by adding the following code to the top of our stylesheet:
$font-header: "CallunaRegular",serif;
$font-size-base: 100%;
$line-height-base: 1;
$color-header: #5a5a5a;
Notice all we’re doing is creating a variable, $font-header, and defining its value, "CallunaRegular",serif.
Now that we have our variables defined, we can insert them into our heading tag styles in the appropriate spot, replacing the hard-coded values like so:
h1 {
font-family: $font-header;
font-size: $font-size-base * 1.5;
line-height: $line-height-base * 1.5;
color: $color-header;
}
h2 {
font-family: $font-header;
font-size: $font-size-base;
line-height: $line-height-base;
color: $color-header;
}
The entire stylesheet will now look like this:
$font-header: "CallunaRegular",serif;
$font-size-base: 100%;
$line-height-base: 1;
$color-header: #5a5a5a;
h1 {
font-family: $font-header;
font-size: $font-size-base * 1.5;
line-height: $line-height-base * 1.5;
color: $color-header;
}
h2 {
font-family: $font-header;
font-size: $font-size-base;
line-height: $line-height-base;
color: $color-header;
}
At this point we should change the file’s extension from .css to .scss. We’re now officially working with a Sass file. And when we compile our Sass file back to CSS we’ll get the following:
h1 {
font-family: "CallunaRegular",serif;
font-size: 150%;
line-height: 1.5;
color: #5a5a5a;
}
h2 {
font-family: "CallunaRegular",serif;
font-size: 100%;
line-height: 1;
color: #5a5a5a;
}
Notice, the variables aren’t included, but rather have been injected into the stylesheet where appropriate, and our newly compiled stylesheet looks identical to what it did when we started.
You’re probably already beginning to see what the benefits of turning values into variables provide us. For one, if we want to make a change to font colors or sizes we only need to change the value associated with the variable and Sass will take care of the rest. We don’t have to worry about changing the value for each property all the way through our stylesheet. Two, using variables in this way allows us to set a base value for properties. Notice we use $font-size-base for our h2 tag and for our h1 tag we use $font-size-base times 1.5. Now whenever we change the value assigned to our $font-size-base variable, the rest of our font sizes will increase or decrease proportionally. Sass handles the calculations and keeps our styles consistent.
Note, a good rule of thumb is to turn any value used more than once into a variable.
Step Two
Find repetitive code and build a mixin of it.
Nobody likes writing vendor-prefixed code. That’s a fact. I mean, consider all the code needed to add a simple box-shadow to a tag:
img, video {
-webkit-box-shadow: 0 8px 10px -6px black;
-moz-box-shadow: 0 8px 10px -6px black;
box-shadow: 0 8px 10px -6px black;
}
It’s a laborious task. But Sass mixins offer some relief.
We can create a mixin for the box-shadow property, including all the vendor prefixes needed, that will keep our code clean and D.R.Y., and one that accepts values as an argument. The mixin could look like this:
@mixin box-shadow($shadow) {
-webkit-box-shadow: $shadow;
-moz-box-shadow: $shadow;
box-shadow: $shadow;
}
We define the mixin with the @mixin directive, give it a name, box-shadow, set the optional argument as a variable, $shadow, which we’ll re-define later, and add a block containing the contents of the mixin, in this case the box-shadow property, all the vendor-prefixed properties and a placeholder for the variable that we’ll be passing in.
To call the mixin, we include it in a tag like this:
img, video {
@include box-shadow($shadow-bottom);
}
We’ll also want to define our new variable, $shadow-bottom, that we’re passing in as an argument for the mixin:
$shadow-bottom: 0 8px 10px -6px black;
Putting it altogether, our Sass will look like this:
@mixin box-shadow($shadow) {
-webkit-box-shadow: $shadow;
-moz-box-shadow: $shadow;
box-shadow: $shadow;
}
$shadow-bottom: 0 8px 10px -6px black;
img, video {
@include box-shadow($shadow-bottom);
}
And after it’s compiled, it will look like this:
img, video {
-webkit-box-shadow: 0 8px 10px -6px black;
-moz-box-shadow: 0 8px 10px -6px black;
box-shadow: 0 8px 10px -6px black;
}
So yeah, it’s a little extra work up front—creating the mixin, defining the variable—but now any time we want to add a box-shadow to any element or class, all we have to do is include our box-shadow mixin. We won’t need to re-write all of those vendor-prefixed properties, we’ll just include the mixin. We won’t need to edit three lines of code when we want to change the look of the shadow, we’ll either tweak our current variable or pass in a new argument, e.g. @include box-shadow(2px 3px 3px rgba(0, 0, 0, 0.5));.
Mixins are incredibly powerful—helping us out with vendor prefixes is the simplest of examples—and can drastically reduce the time it takes us to write code, while at the same time keep our code clean and efficient.
Step Three
Get responsive with nested media queries.
Let’s take another look at our heading styles from the first example. This is where we left off with our h1 styles:
h1 {
font-family: $font-header;
font-size: $font-size-base * 1.5;
line-height: $line-height-base * 1.5;
color: $color-header;
}
Now let’s say we want to change the font-size, line-height and color display on small screens. We do this using @media. But now that we’re using Sass, we can nest the media query rules right along with the rest of the h1 rules like so:
h1 {
font-family: $font-header;
font-size: $font-size-base * 1.5;
line-height: $line-height-base * 1.5;
color: $color-header;
@media only screen and (max-width : 320px){
font-size: $font-size-base * 0.75;
line-height: $line-height-base;
color: black;
}
}
The compiled CSS will look like this:
h1 {
font-family: "CallunaRegular",serif;
font-size: 150%;
line-height: 1.5;
color: #5a5a5a;
}
@media only screen and (max-width: 320px) {
h1 {
font-size: 75%;
line-height: 1;
color: black;
}
}
So what benefit does this provide us? It saves us time, eliminating the need to create a separate declaration for each new set of styles. Sass does that for us. And though the CSS compiled from Sass might not be as easy to read as if we wrote vanilla CSS media queries, ideally the only thing that should ever have to read your compiled CSS would be another computer—your compiled CSS should be production-ready, meaning minimized and not something to be further edited. Also, in my opinion, being able to set media query specific rules right next to those they’re modifying makes more sense logically and, for me, enables faster responsive design coding. In a one-rule example, these benefits may not seem significant. But if you’re ever tasked with making an entire site responsive, you’ll quickly see the advantages of going the Sass way with nested media queries. Trust me.
In Conclusion
Ruby. Compiling. The command line. These are the reasons it took me so long to get started with Sass. I bet these are some of the main reasons most people are hesitant to make the move to Sass. But once you get to it, setting everything up really isn’t that difficult. The documentation on how to do it is pretty straight forward. (I never studied a lick of programming and was able to figure it out in less than half an hour using Cygwin on Windows.)
And as soon as you compile your first stylesheet—you tackle step one—you’ll begin to see the payoff. By the time you’re up to step three you’ll be wondering how you ever lived without it.
Do yourself a favor and give it a try. Take a weekend, some old code and see what happens. I’m willing to bet you’ll never look back.
[…] Getting Started with Sass […]