Video icon 64
Want to be a web designer? Skill up fast with video courses from Tuts+. Start your free trial.
Advertisement

5 Reasons for Picking up Sass *Today*

by

"I hate the console, I don't do Ruby and I don't care for variables. Why in the world should I learn Sass?" Stop faffing about and listen up...


1. It's Really Easy!

You already know Sass! Yes, You do.

Sass has the exact same syntax that CSS has. Coincidence? Nope. Sass was built so that designers like yourself can pick it up easily and learn all the additional perks at their own pace, if they want to.

No Terminal

When I first saw Sass, as soon as I the word "terminal" I turned the other way. It's not that I'm afraid of the terminal, it's a very useful tool and I've been using it (when absolutely necessary) for years, but I simply prefer a user interface. If there's no UI, I won't be using it.

Guess what? I found out that there are several options.

I've used CodeKit since it was in public Beta. In all that time I've used the terminal for Sass about three times, and I could have avoided that entirely as well.

No Pressure

So you don't like Variables. And why in the world should you spend time wrapping your head around mixins, functions and all that jazz? Well, you don't. Sass isn't going to punish you for that. However, I can promise you that even with your purest intentions, you're going to find yourself using them sooner or later. Not because you'd have to, but because you'll want to. Same goes for mixins.

Even if you are never, ever going to write a single Sass function or a mixin, you're still going to use them eventually because you'll find more and more frameworks that do the hard work for you, letting you benefit from that work by using a mixin.

@import

So let's imagine you'd like to use normalize.css for your next project. How are you going to do that? Add another link tag to your HTML? Or maybe just use an @import statement in your CSS? In both these cases you're adding extra HTTP Requests; perhaps not that big of a deal, but it's not optimal, and not best practice.

You could just simply copy the contents of normalize and paste them into your stylesheet, but suddenly your CSS file becomes a mess and you haven't even started your project! Then what will you do when normalize.css updates? Copy and paste all over again?!

In Sass you could just use the good ol' @importstatement and let Sass pull your normalize.css into your stylesheet.css (you would have to rename the files to .scss instead, but again - not a big deal).


2. CSS is Wet

DRY (Don't Repeat Yourself) principles are often referred to in actual programming languages, but there is no reason why they shouldn't be applied to some extent in CSS. After all, wasn't that the reason CSS was invented in the first place? Instead of specifying styles over and over again in your HTML, you could suddenly create a class name and declare all your styles there.

However, as soon as you start importing code made by others (like frameworks, resets etc.) you're likely to repeat something.

For example, normalize.css sets the default body font to "sans-serif". I like it, it's a good default. But what if we want to use a custom font? Should we edit normalize.css? And what if normalize is updated ? We'll have to do it all over again.

In the end we probably end up using @import in CSS.

Now we just have to make sure that we're including our normalize at the top of our stylesheet and we're good to go. We'll override the font-family, then just to be sure let's slap an !important statement on the end, right? Wrong!

Sadly, normalize.css isn't written in Sass (yet), but there are good people who have converted normalized.css to Sass, which you can just use in your CSS. For example:

$font-family: "Comic Sans";

Of course you should be using Normalize 2.0.1+ already, which doesn't include a font-family declaration anymore, but this was more an illustration of the problem and solution for it.


3. Stay Ahead of the Curve!

CSS is an evolving language. If you're still thinking variables are bad, consider this CSS Specification, which provides the following example:

:root {
  var-header-color: #06c;
}

h1 { background-color: var(header-color); }

Well, if that isn't an ugly version of a variable I don't know what is!

The point is that CSS is a language that is evolving, so even if you ignore pre-processors for as long as you can, there will be a point in future where you are going to be forced to learn variables anyway. My advice is to stay ahead of the curve and adopt things like variables early on!

And it's not just the Variables! Sass and other preprocessors have a good deal of influence on the future CSS Specifications. Here is another specification in development, which is going to allow CSS code nesting in the future. It will look something like this:

/*The following example using Hierarchies:*/

div, p {
	& .keyword {color: green;} 
	font-size: 10px;
	& .constant {
		color: red;
		&:hover:after { content: " [" attr(value) "]";}
		background-color: green;
	}
}
/*...produces the same results as the following CSS:*/

div, p {font-size: 10px;}
div .keyword, p .keyword {color: green;}
div .constant, p .constant {color: red; background-color: green;}
div .constant:hover:after, p .constant:hover:after {content: " [" attr(value) "]";}

In the case of the specification, no code is actually compiled, this is simply how CSS will likely look in the future!

Influence the future

CSS Specifications aren't created by a bunch of peculiarly creative aliens who want to control our web lives remotely from a galaxy far far away. No. Specifications are developed by people, which means that other people, specifically developers and designers (like yourself) have influence over which specifications are being developed. By using pre-processors like Sass, you're participating in something much more. You're pushing the technology further.

If you come up with an idea, or a feature request, you can ask for it, or just simply participate in the discussion on how a specific feature should behave and whether it is needed at all.


4. Benefit From the Community

Thanks to the community surrounding Sass, there are tools developed by others which you can take advantage of.

ZURB, for example, built a large framework called Foundation for Sass.

If you prefer something more light-weight, you might consider Inuit.css.

Then of course there is Compass, which provides a framework with tons of useful options..

..as indeed does the slimmer Bourbon.

Let's say you're feeling adventurous today and are thinking of using "rem"s as a unit of measurement. How do you use rems providing fallbacks for outdated browsers which don't support them? Happily, you just declare the font-size twice; once in pixels, then again in rems for browsers who will understand and parse it.

h1 {
font-size: 16px;
font-size: 1rem;
}

This would probably your best bet, but means that anywhere you want to use a rem, you'd have to type it twice. Also, whereas 16px = 1rem is an easy calculation, what if you need 19px? Now do the math in your head. Can you? Yeah, I used a calculator too (1.1875rem).

Because in the Sass community there are some awesome guys, you can quickly search Github and download this _rem.scss file (which looks pretty intimidating, doesn't it?), import it (we'll talk about importing in a moment) and now you can magically do:

h1 {
  @include rem(font-size, 2rem)
}

at which point Sass will automatically convert that to

h1 {
  font-size: 36px;
  font-size: 2rem;
}

If the day should ever come when you can drop rem fallback support, you won't have to do a Regex search and replace all of your documents. You can just add this in the top of your stylesheet.

$print-rem-px-fallbacks: false;

I think you might guess what this "print rem px fallbacks" setting does :)

Yes. We used three Sass features in this example, a variable, a custom mixin and an "import" statement, but was it really that difficult?


5. Shortcuts

So here's a thing you're going to be doing for the rest of your Web Developer life. Defining link colors. You know, this kind of thing:

a {
  color: blue; 
}
a:hover {
  color: yellow; 
}

It's a commonly repeated task, but I'm not going to suggest that you roll your own Sass Mixin for this kind of thing. Instead, why not use Compass (a Sass Framework)?

a{
 @include link-colors(blue, yellow);   
}

This is going to be compiled to the exact same thing as above. And it read pretty well too ("include link colors: blue and yellow"), just in case you're wondering how that works, visit compass documentation.

If you're using any editor that supports snippets, you can set up (or download) a snippet to automatically prepend @include to your statements (don't let that scare you).

Sass itself provides a ton of very, very useful features. Even though the Sass Documentation isn't the prettiest of all things (from a designer's perspective), it contains a lot of very useful information about Sass features, for example one of my favorite functions in Sass - Color Functions. I don't have to open up Photoshop anymore to experiment with color if I need a variation. I can simply do this kind of thing:

a {
  color: lighten(black, 10%);
}

Which is compiled into

a {
  color: #1a1a1a; 
}

Conclusion

Sass isn't that ruby thingy that hardcore developers use. It should inspire you, the designer, and help you with your every day work. It's not a programming language, it's a Web Frontier.

Sass can be as easy as you want it to be. If you're curious about whether you can do something in Sass, just quickly search google, you might be surprised!

Most importantly of all - stop faffing about and start using Sass today, especially if you want to stay ahead of the curve! And keep your eyes open for all the Sass tutorials, pick which features of Sass you like, and use them!

Advertisement