Sass And LESS: An Introduction To CSS Preprocessors

Posted: 09 Apr 2012 05:30 AM PDT

In recent weeks I’ve been looking a lot at css. I’ve looked at abstracting css, changing best practices and how to make our css more modular and scalable. In many of these posts I’ve alluded to css preprocessors and it’s time we start talking about them.

Today I want to look at css preprocessors in general. What they are, how they work, why you might or might not want to use one and which one might you choose. I’ll show you some of the basics of Sass and LESS too.

In a followup post next week or maybe the week after I’ll dig a little deeper into some real code, but here I want to keep things more general as way of an introduction.

What Are CSS Preprocessors?

The answer is in the name. If you understand how php or asp or any other server side programming language works it amounts to the same thing. In fact the first preprocessed css I encountered were css files ending in .php in order to use variables.

CSS preprocessors take code written in the preprocessed language and then convert that code into the same old css we’ve been writing for years. 3 of the more popular css preprocessors are Sass, LESS, and Stylus

Because they aren’t css, they aren’t bound by the limitations of css.The preprocessed language can give you more functionality than css as long as it eventually makes sure everything is output as css and works in a browser like we expect.

Why Use a CSS Preprocessor?

Because they aren’t css, they aren’t bound by the limitations of css. (Where have I heard that before?) It’s really as simple as that. CSS is great, but it doesn’t always let us do everything we’d like.

For example many developers want more abstraction than css gives us by default. One goal of css has been to keep it simple so anyone can quickly pick up the language and learn. However that focus also limits what css can do and developers don’t much like limitations. We want variables and if the language won’t gives it to us, we’ll find a way to give it to ourselves.

Preprocessors offer more than variables of course. They can offer whatever they want as long as the resulting css file they produce works as ordinary css.

You don’t have to use a preprocessor, but you’ll find most people who use them for any length of time will insist they’ll never go back. They won’t give up all the extras the preprocessor offers as those extras allow them to write more flexible and maintainable css quicker than they could without.

Possible Issues with CSS Preprocessors

At the same time there are potential issues to using a preprocessor, which keeps some away. The main issue is that everyone working on the site needs to be using the same preprocessor. Part of your team couldn’t work in Sass while the some others use LESS and others still edit the css files directly.

Even if you don’t work in a team you may have issues with clients or other developers working on the css before it gets back to you. This won’t break the site, but once the css file is edited directly, your future work will be in the css file as well. Not exactly the worst thing in the world and many who use css preprocessors will tell you they still find great benefit in using them initially even if they can’t later use them for maintenance.

You’re also working locally when using a css preprocessor instead of editing files on the live site. Quite honestly that’s a good thing even though many of us, myself included, still continue to practice cowboy coding, editing files live on the server. Ideally our process should be:

Work locally
Use version control
Deploy to staging server
Deploy to live server

One potential issue for some is the command line. Those who use the command line will tell you you’re better off using it anyway, but there are more than enough apps with pretty GUIs for those of us who prefer them. I’m currently using CodeKit while I learn, but there are other apps like Live Reload offering a nice GUI.

Overall I don’t see most of the above as big issues and in time most css like most html today will likely be preprocessed.

Which CSS Preprocessor Should You Use?

That’s really up to you. To be honest I don’t know the different languages well enough yet to offer reasons why one is better than another. One of the things that kept me away from trying any of them was not being able to decide which to use, which is pretty silly as they’re all very easy to learn to use.

I’m currently going with Sass, using the .scss syntax. My choice is mainly based on the advice of Chris Coyier who’s written about all this stuff a few times over the last year. I figure if Sass is good enough for Chris, it’s good enough for me too.

I have a hunch I’ll look into the other languages too and CodeKit is capable of working with several so it should be easy enough to explore a few.

I’ll leave you with a few links to articles that compare some of the different css preprocessors to help you make a decision. LESS and Sass are the two most popular choices with plenty of tutorials online for each. You’re probably fine with either one.

Sass vs. LESS vs. Stylus: Preprocessor Shootout — code examples of all three from Nettuts
8 CSS preprocessors to speed up development time — a quick mention of a variety of different preprocessors
New Poll: Your Preferred CSS Preprocessor Syntax — poll from CSS-Tricks. There’s good info in the comments

How Do CSS Preprocessors Work?

Like I said above I’m working on a more detailed demo, but I wanted to show a few quick basics for working with css preprocessors. Below are a few of the very basics. I’ll show you code in both Sass (.scss syntax) and LESS and what the css output would look like.

Variables — alone are enough for me to give preprocessors a try. It should be obvious that changing the value of a variable once is much more maintainable than changing the many instances of it’s value spread over a css file.

 /* -- .scss --  */ $color: #efefef; body {background:  $color;} /* -- .less -- */ @color: #efefef; body {background:  @color;} /* -- resulting css -- */ body {background:  #efefef;}

Hopefully you can see how much more maintainable it is to use the variable as you could update a color scheme across your entire site by changing a handful of variables.

Interpolation — expands on variables in that you aren’t limited to the values of css properties.

 /* -- .scss --  */ $side: top; border-#{$side): 1px solid #000; /* -- resulting css -- */ border-top: 1px solid #000; /* -- .less -- */ @base-url: "http://example.com"; background-image: url("@{base-url}/images/bg.png"); /* -- resulting css -- */ background-image: url("http://example.com/images/bg.png");

Operations — come in handy, especially as we’re moving toward web design and development based on proportions over fixed measurements.

 /* -- .scss --  */ $navbar-width: 800px; $items: 5; #navbar li {width: $navbar-width/$items - 10px;} /* -- resulting css -- */ #navbar li {width: 150px} /* -- .less -- */ @base-color: #111; #header {color: @base-color * 3;} /* -- resulting css -- */ #header {color: #333;}

Both languages take this further by offering functions such as lighten(@base-color, 10%) in LESS. A similarly named function exists in Sass and there are many more functions in both languages.

Mixins — allow for the easy reuse of blocks of code.

 /* -- .scss --  */ @mixin rounded-corners {   $radius: 5px;   border-radius: $radius;   -webkit-border-radius: $radius;   -moz-border-radius: $radius; } #navbar li { @include rounded-corners; } #footer { @include rounded-corners; } /* -- .less -- */ .rounded-corners  {   border-radius: @radius;   -webkit-border-radius: @radius;   -moz-border-radius: @radius; } #header {.rounded-corners;} #footer { .rounded-corners;}  /* -- resulting css -- */ #header {   border-radius: 5px;   -webkit-border-radius: 5px;   -moz-border-radius: 5px; } #footer {   border-radius: 5px;   -webkit-border-radius: 5px;   -moz-border-radius: 5px; }

LESS does things a little differently here. The initial mixin is a regular css class that later gets added where you want. My understanding is this isn’t the ideal way to handle mixins, but I don’t yet know enough to agree or disagree.

Nesting — One last thing I’ll mention is how both Sass and LESS allow for nested formatting and they work in the same way. Notice how the list, list items, and link are nested within #navbar.

 /* -- .scss or .less -- */ #navbar {   width: 80%;   height: 25px;   ul { list-style: none; }   li {     float: left;     a { text-decoration: none; }     &:hover { text-decoration: underline;}   } } /* -- resulting css -- */ #navbar {width: 80%; height: 25px;} #navbar ul {list-style: none;} #navbar li {float: left;} #navbar li a {text-decoration: none;} #navbar li a:hover {text-decoration: underline;}

A few months back Jason Zimdars wrote about how 37signals was using nesting to regain control over the css cascade. It’s an interesting read.

The above examples only scratch the surface of what you can do, but hopefully you can see it’s pretty simple to write “css” in a preprocessed language. I’m still new to this, but even after playing with some real code for an hour or two I can assure you both Sass and LESS are quite easy to use and I assume it’s similar with others like Stylus.

Additional Resources

I collected a lot of links while looking at preprocessors and figured why not share. The first group is focussed on Sass and Compass, which is a framework built on top of Sass.

This next group as you can tell is focused on using LESS.

This last group is a little different. The first is a general post about css preprocessors from Chris Coyier. It leans toward the Sass/Compass side, but talks about most everything I have here.

The remaining links are all podcasts. With the first two of these the conversation is mainly about preprocessors. The last is about css in general. The preprocessor talks is around 22 minutes.

Summary

CSS preprocessors are a way to add functionality to css mainly in the form of abstraction like variables and mixins. They offer extra things you can’t do in css alone that can make development quicker, easier, more maintainable, and more scalable.

There are some potential issues such as needing to get the team on board and making the commitment to giving up editing live files, though these aren’t too hard to overcome and the latter is something we should do regardless.

There are plenty or css preprocessor to choose from. LESS, Sass, and Stylus are 3 popular choices. I’ve chosen to use Sass with the .scss syntax, though I’ll probably give both LESS and Stylus a look at some point.

If you look through the code examples above you can see Sass and LESS aren’t hard to use. I began working with Sass a few nights ago and within a few minutes I was woking comfortably. I know these languages have more complex functionality, but the basics are as easy to use as css, especially if you already know css.

Bear with me for another week or two while I put together something of a more detailed demo for a realistic web page.

Are you using or have you used a css preprocessor in the past? If so which language and why? Has it improved your development? If you haven’t yet given css preprocessors a try is there a reason?