Why I Fell in Love with the Sass CSS3 Extension, And You Will Too!

by 6 04/26/2012

In some ways I’ve always been a traditionalist. I like writing my code from scratch, without preprocessors and frameworks. I feel like I have more control over what I’m doing. Recently, however, I finally took a proper look at Sass – the CSS3 extension – and I have to say that I’ve kind of fallen in love with it!

What is Sass?

Sass is a CSS3 extension, which is a CSS extension that runs using Ruby. It’s a super easy install, and once you’re up and running you can start using SASS on any project, whether Ruby based or not.

Sass really extends the functionality of CSS, and gives you a lot of control in writing flexible stylesheets. The Sass files you write are translated into standard CSS as you work. You can use partial files, variables, nest your selectors, easily reuse CSS, or inherit styles.

Some basic uses of Sass in a project

There are two different syntaxes for Sass. I’m working using the newer SCSS syntax, which I find is far easier to get used to than the older indented SASS format. SCSS pretty much expands upon existing CSS syntax, rather than changing it, so it’s very accessible. If you know CSS, you’ll probably be able to work out SCSS pretty easily simply by looking at some code.

In my project, I’ll have a “css” folder, and inside that I’ll also have a “sass” folder. Running Sass from the command line, the .scss files I write will be automatically collated into CSS. So, I’ll start with a “style.scss” file within the sass folder, and that will create a “style.css” file.

Nesting your code

Although I talked a while back about trying to avoid repetition with a class based approach to CSS, it’s still an annoying part of code. Sass removes much of that annoyance through nesting. e.g. I want to target styles on various aspects of an HTML structure;

<section id="main-content">

  <article class="post">

    <h2>The Title</h2>

    <p>Some text content</p>

  </article>

</section>

Using standard CSS I’d do something like this;

#main-content
{
  background: rgb(255,255,255);
  font-family: sans-serif;
  width: 640px;
}

#main-content .post
{
  border: solid 1px rgb(0,0,0);
  padding: 20px;
}

#main-content .post h2
{
  font-weight: bold;
}

I’ve had to write “#main-content” three times in order to target different elements nested in that section. Using Sass, however, I can nest my code like this:

#main-content
{
  font-family: sans-serif;
  width: 640px;

  .post
  {
    border: solid 1px rgb(0,0,0);
    padding: 20px;

    h2
    {
      font-weight: bold;
    }
  }
}

The code is simpler, more elegant to read and understand, and will be collated into the appropriate CSS.

Easy partials

I can create partial .scss files to import into my main Sass file easily. I just create an additional file in the sass folder, e.g. “_partial.scss”. Then in my main “style.scss” file I add;

@import "partial";

I can add this import command anywhere within the master sheet.

This is obviously very similar to the standard @import in CSS. The different being that because the Sass file automatically collates into a single CSS which you *then* deploy, there aren’t additional http requests to bring in additional stylesheets.

Mixins

I really like mixins. Mixins allow you to create a chunk of CSS, which you can then target at any element within your .scss code. This is really useful for styling that you commonly apply to different elements of a page.

e.g. I have some styling that I know I’m going to apply regularly to blocks of text, and so I create a mixin:

@mixin text-box
{
  background: rgb(255,255,255);
  border: solid 1px rgb(0,0,0);
  border-radius: 20px;
  padding: 20px;
}

I can now reuse that mixin and target it at different elements. Let’s say I want to apply it to the #main-content section in the example above:

#main-content
{
  font-family: sans-serif;
  width: 640px;
  @include text-box;

  ...etc
}

Mixins make it a breeze to have styling snippets that can be easily re-used.

Is there a down side?

From a workflow point of view, I don’t see one. I’ve always been confident that I’m a really fast coder, which is probably one of the reasons I didn’t adopt Sass early. But Sass has made my implementation of CSS much much faster, and with little to no learning curve.

The only downside is in file efficiency. The collated final CSS file that you deploy can sometimes become a little over complex. It’s not enough to have a significant impact (and Sass does well at minifying the file), but it is going to make life difficult for someone needing to make direct CSS changes.

On balance, however, I can’t see any strong reason not to use Sass.

Give Sass a try

This isn’t intended to be a comprehensive overview of all of Sass functionality, just a brief introduction. I haven’t been working with Sass for that long, and I’m already discovering more and more additional functionality.

It’s incredibly easy to install and start using, and the development of the .scss syntax means that it’s far more accessible to anyone who’s familiar and comfortable with standard CSS. I’ve found it a complete joy to work with.

Print Friendly

About 

Robin Cannon is Front End Engineer at Viggle, Inc. He also blogs regularly on his site Shiny Toy Robots.

Get our Daily Newsletter

Get conversion optimization, design and copywriting articles delivered to your inbox FREE

6 COMMENTS

Josh

You should also check out lesscss. We’ve compared both before adopting lesscss – we just liked the less toolchain a hell lot more. :-)

April 27, 2012 Reply

Robin Cannon

Yeah, LESS is definitely another legitimate option. What’ll be interesting is seeing the long term “market penetration” and how that impacts developers. A few years ago there was no real consensus on Javascript libraries, and now jQuery has a pretty dominant position. I can see a similar consolidation happening when it comes to CSS preprocessors, particularly as the support for the more advanced capabilities of CSS3 becomes more widespread.

April 28, 2012 Reply

Nod

wtf you shouldnt write #maincontent 3 times, hell you shouldnt even use IDs!!

just use classes people!
dont buy into these pseudo css tools, dont be lazy and code!!

May 1, 2012 Reply

Robin Cannon

Of course you should use IDs. They exist for a reason, with a different purpose to classes. They’re also far faster to target with script, e.g. jQuery, than a class – because they’re unique.

I was of a similar opinion to you on SASS as a CSS tool until I tried it. The increased speed of coding makes development and deployment much faster, and the output is perfectly valid CSS.

May 1, 2012 Reply

    Russ Henneberry

    Different strokes for different folks but I like the sound of making development and deployment faster and easier.

    May 3, 2012 Reply


Leave comment

Some HTML allowed

Get conversion optimization & A/B testing articles FREE >>>