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

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.

About 

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

Comments

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

  2. Robin Cannon says:

    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.

  3. 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!!

  4. Robin Cannon says:

    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.

Trackbacks

  1. […] for hovering on, and hovering off. Second, we use a timing of 0s to disguise the hover on.Why I Fell in Love with the Sass CSS3 Extension, And You Will Too! – In some ways I’ve always been a traditionalist. I like writing my code from scratch, without […]

Comment Policy:

Your words are your own, so be nice and helpful if you can. Please, only use your real name, not your business name or keywords. Using business name or keywords instead of your real name will lead to the comment being deleted. Anonymous commenting is not allowed either. We rarely allow links in your comment. We accept clean XHTML in comments, but don't overdo it please.

Speak Your Mind

*