Doing Our Homework: Sass, Grids, Resets and CSS Frameworks

Refresh Chicago, October 2010

Blueprint, Sass, reset.css, 960.gs, Compass... the list goes on. What happened to CSS? It was so simple and elegant; it made designing the web fun and easy. Then a bunch of smart people realized it could be better. And now it is better, but figuring out how to manage all these libraries, paradigms and snippets is a real pain in the ass.

So let's set some things straight. We'll start by talking about why CSS frameworks exist in the first place and why some are more popular than others. Then, in the spirit of css Zen Garden, we'll style a body of markup starting with a reset all the way up to color, typography and layout. Along the way we'll our site come to life in IE, Webkit and Gecko.

Download the source for this demo.


So What is This About?

Sass
What is it? Why are we using it for this demo?
Resets
Why should we use them? Where should we draw the line?
Grids
We know why we use them, but how can get the most out of them?
CSS Frameworks
What should they do? What shouldn't they do? Which one should we use?

Sass

Sass is new way to write CSS. You write your styles in with Sass and then compile them to CSS. In the latest version you can utilize the same syntax as CSS, too. Sass is good for CSS. Why? Well for a number of reasons.

In programming it's good to follow the rules of DRY code. That means Don't Repeat Yourself. Sass allows you to write less code in the form of functions, called mixins. You can then include these mixins to reuse styles you've already composed.

My favorite benefit of using Sass is cleaning up your markup. Instead of this:

<div id="user" class="grid_10">
  <p id="name" class="large">Avand Amiri</p>
  <p id="email" class="small gray">avand@avandamiri.com</p>
</div>

...you just get this:

<div id="user">
  <p id="name" class="large">Avand Amiri</p>
  <p id="email">avand@avandamiri.com</p>
</div>

The style information for the classes grid_10, small, large and gray can now be symantically associated to the element by id.

Sass still allows you to abstract the definition of those styles. You can write mixins and include them to create abstractions. Or you can remove unnecessary repetition with constants

$gray = #ccc;

@mixin small {
  font-size: 11px;
}

#user {
  #email {
    @include small;
    color: $gray;
  }
}

Resets

Every browser has it's own way of rendering the DOM. This becomes a problem when you want everything to look the same. So the solution is to provide all browsers a set of styles which will clear the slate. This way you can build up with just the styles you need.

The effects of building on top of a reset are tangible:

  1. Consistent visuals across all browser
  2. No surprises - things look the way you intended

Of course, it's not all upside. In the end you end up writing more code to recreate the styles some browsers give you by default. You also need to ask the question of what needs to be reset? This can be tricky to answer and requires one to think. Depending on your mood this could be a pro or con.

Ultimately, a reset is not a silver bullet. There's a few examples of resets available on the web; take what you need and discard the rest.

To go about building or customizing a reset you want to keep a few things in mind:

Grids

CSS grids serve to dive a page into a certain number of columns. Content then spans these columns. Grids create visual alignment as well as making it easier to position elements on the page.

If you're using a grid to control your layout, you'll deal with fewer layout surprises, especially with Internet Explorer.

They are very simple, but unfortunately, can muckup your markup - unless you use something like Sass to keep things clean.

Here's how they work:

<div id="foo">
  <div id="bar">
    ...
  </div>
</div>
#foo {
  margin: 0 auto;
  width: Xpx;
}
#bar {
  display: inline;
  float: left;
  margin-left: Ypx;
  margin-right: Ypx;
  position: relative;
  width: Zpx;
}

CSS Frameworks

CSS frameworks serve to organize everything described above: Sass, resets, grids and sometimes even JavaScript. These files are organized into a loose library that one can than include in their project. However, they're unlike most code libraries because it's really just copying and pasting files into your project. As a result, I think, it's fair to take what you need and discard the rest.

There's a lot of these frameworks:

Framework Type Reset Colors Layout Prototype jQuery Simple?
Elements nope yes yes yes yes nope nope
YAML maybe maybe maybe maybe maybe nope nope
YUI 3 yes yes nope yes nope nope nope
Boilerplate yes yes nope nope nope nope yes
Tripoli yes yes nope yes nope nope meh
HTML5 Boilerplate meh yes meh nope nope yes nope
960 Grid System meh yes nope yes nope nope yes
Atatonic yes yes meh yes nope nope yes
Less Framework 2 yes yes meh yes nope nope yes
Blueprint yes yes meh yes nope nope nope

What about forms?