Sass And LESS: An Introduction To CSS Preprocessors

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.

CSS

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.

A group of ants displaying teamwork

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.

Main interface of the CodeKit application

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.

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.

1
2
3
4
5
6
7
8
9
10
/* -- .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.

1
2
3
4
5
6
7
8
9
10
11
12
13
/* -- .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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
/* -- .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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
/* -- .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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/* -- .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.

Sign for NY State Adopt a Natural Resurce program

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?

Download a free sample from my book, Design Fundamentals.

6 comments

  1. Hi Stephen,

    Nice work here with some excellent food for thought. In all honesty, i’ve been starting to feel a little behind the game in the last year or so. I’m a fan of chris coyier and have been for serveral years, but i have, purely through lack of time to commit, fallen a little out of my comfort zone when hearing about sass, LESS, responsive etc.

    I found your post has offered me enough insight to at least get things moving in terms of giving sass a go.

    I’m not sold by any means, but certainly excited at the possibilities of how this could change what i’ve been used to doing for years.

    Can i ask you a few questions whilst i’m here, just to get your thoughts and opinions on a few other items that are lingering at the back of my mind…

    1. What are the benefits of command line and should i be using it?

    2. I feel responsive design, although clearly beneficial will have a negative impact in terms of the time it takes me to reproduce designs in css/html. is this correct?

    3. What responsive resources could help me get moving quickly. e.g frameworks, boilers etc.

    4. In an attempt to do the honorable thing, i’ve always held back my drive towards new technologies due to older browsers such as IE6/7, and feel now that i’ve cut my nose off to spite my face as i’m ‘out of date’. Can i finally ditch these two or not?

    Thanks again. I’ve just subscribed to your feed. keep up the good work, look forward to reading more

    • Thanks for the compliments Roy. I hear you about trying to keep up. It seems like every day some new technology comes along and someone is telling us how we all need to learn it right now.

      As for your questions I’ll do my best to answer.

      1. The general benefits of the command line is you can usually accomplish the same task quicker and the command line usually allows you to do more. I don’t use it a lot myself. I’m more a visual person. You don’t need to use the command line, but if you get good with it, it’ll help you be more productive.

      2. The first time you build a responsive site it will take longer. Each time after it get’s a little quicker. It may never be as quick as developing a fixed-width site, but it really doesn’t have to take a ton more time.

      3. I don’t use any responsive frameworks. I tend not to use frameworks in general. I have started using parts of the html5 boilerplate. Two responsive frameworks I keep seeing people talk about are Foundation and Skeleton, though I haven’t used either.

      4. Whether or not to ditch older browsers like IE6 and IE7 depends on the audience for the site. I can’t say I really support either, though at the same time, most sites I build should work in either. They probably won’t look exactly the same as in other browsers, but they don’t have to.

      Look into progressive enhancement. The idea is to start with a minimal site that will work most everywhere and then add more for those sites that are more capable. It’s not as hard as it might sound.

      For example older browsers don’t understand the css for border-radius. No big deal. They’ll ignore the property and show a right angled corner while those browsers that do understand it will show the rounder corner. Sometimes it’s as simple as that. The big thing to accept is that your site doesn’t have to look exactly the same in every browser.

      Thanks for subscribing and hope something in my answers above was helpful.

      • Thanks for your answers to my questions Stephen, they are certainly most helpful.

        It’s reassuring to learn that i’m not too far off the pace and with some subtle movement in the right direction i’ll certainly be feeling more comfortable again.

        You’ll be pleased to hear that since reading your post, you’ve inspired me to just have a go. I’ve managed to get the wheels turning (albeit quite slowly at the minute) on a little experimental project.

        Keep up the good work and thanks again.

        • Glad I could help Roy. You seem to be moving in the right direction. One thing to keep in mind is there are always new things to learn. It never ends and you don’t need to jump on everything you read about. Pick those you think important and learn what you can,

          Cool that I could inspire you. I hope your experiment goes well. Feel free to share if and when you’re ready.

  2. I haven’t tried SCSS (or CSS preprocessors in general) yet. I’m wondering if it slows you down in the debugging phase as you would have to integrate changes made in say Chrome on the fly in your compiled CSS to the SCSS sheet?

    Cheers

    Pete…

    • I’ve only recently started using SCSS is production. For awhile I was just playing around. So far I haven’t had any problems debugging. I think the main complaint some people have is a debugger giving them a line number from the css file, which doesn’t map to the .scss file. That hasn’t been an issue for me.

      One thing I did notice with a site I’m working on now is making changes, once I’ve pushed things to the server. This site isn’t live, but it is on the server. Sometimes I just want to make a quick change to the css file on the server, but know I should be working in the .scss file locally.

      That’s less a problem with SCSS though and more with me not having the best version control set up at the moment, something I hope to incorporate soon.

      My suggestion is just play around with SCSS. I started slow. I began by playing around and then I started using it for some demos here. Once I felt comfortable I started using it on real projects. There’s a small bit of adjustment, but it really hasn’t been much for me. If anything I’m looking forward to taking better advantage of what SCSS can do.

Leave a Reply

Your email address will not be published.

css.php