Category Archives: XHTML / HTML

Scope donuts

Note: This article is esoteric-could-be-should-be wishing for future browsers. If you only like to hear about what you can use right now, you won’t like this. You’ve been warned. ;)

At first, when the HTML5 working group added the scope attribute I was skeptical. I thought, “oh dear, this is going to be another way for developers to cause massive duplication and inconsistency.” I still do worry, but I’m more excited about the tool and hoping we can also find really great things to do with it.

Scope is great for mashups

The first that comes to mind, and the reason it was created, is mashups. Imagine you want to pull in a twitter feed or a video into your page. Unless you intend to rewrite it all (and often widgets block such fine grained control), you’ll probably be allowing someone else’s CSS onto your page. That can be daunting to say the least.

For example, the twitter widget I use pulls in ~1.36kb of CSS that could potentially interfere with my site styles — and it does it via JavaScript, so unless I’m ready to switch to using the API rather than a widget, I’m stuck allowing their styles on my page.

The way to sandbox those styles today is to be sure each style starts with a twitter specific class name. You can see from their code that they did a very good job of it. None of their styles will be polluting mine. Unfortunately, not all widget CSS will be so enlightened (especially not ad code). HTML5 offers another option for allowing authors to sandbox styles called the scope attribute. David Storey has a much better explaination of scope on his blog, I’ve adapted this example from his:

<div>
  <style scoped>
    p { color: blue; }
  </style>
  <p>The text in this paragraph will be blue</p>
  <p>And in this paragraph too</p>
</div>
<p>This paragraph is out of scope so will be gray</p>

If your browser supports it, it will look like this:

The text in this paragraph will be blue

And in this paragraph too

This paragraph is out of scope so will be gray

There are a lot of really great use cases for this, widgets, ads, even large companies with multiple teams putting functionality on a single page. On the other hand, there is a use case for which it falls flat: components. I’d love to see it extended so it could work for both.

Scope is more than a starting point, it’s a donut

donuts
Donuts by mamaloco

The interesting thing about UI components (different than ads or widgets) is that they can sometimes contain other unrelated components. You can have a tabset that contains headings, paragraphs, media blocks, or even (holy ugly!) another tabset. Ideally, you would scope the CSS of the tabset to the tabs only, so it can’t bleed outward and change styles on the rest of the page, but you also want to prevent the styles from bleeding inward to content components. So we need a way of saying, not only where scope starts, but where it ends. Thus, the scope donut. The styles affect the donut shape, but not the other components which can be found in the donut hole.

Tabs from the admin section of Let's Freckle, a time tracking app.
Figure 1: Tabs from Let’s Freckle, a time tracking software.

It has always struck me as odd that scope is declared in the HTML, because ideally with reusable components you wouldn’t want to repeat that code all over the place. Each of the tabs has different content related to my Freckle settings. The content styles aren’t specific to the tabs, but may also be used in other parts of the page. We want to make that reuse possible, by keeping our tabs from affecting the way content (the components in the donut hole) components look. I’d like to do this once, in the CSS, and then have it apply anywhere the component is used.

The first step is to be able to define that component, including both it’s HTML and CSS. Let’s start with a basic box. It’s HTML might look something like this:

<div class="box tabs"> 
    <div class="hd">
    	  Box Header
    </div>
    <div class="bd">
        Box Body
    </div>
</div>

The scope of a box begins at the wrapper div with the class box, and ends at the box body. We don’t for example want the styles on the box spilling over into whatever content we put in the box. I’m not sure how exactly to say this in CSS, but I like the idea that using nested selectors implies meaning about the relationship of those parts. e.g. nesting the selectors means that the sub nodes belong to the same component.

In other words, if I applied a text color to my box, it would change the color of text in the header, but not to subnodes in the body. Let’s take a look at an example syntax. I don’t really know what the right syntax is, but I’m more and more convinced it is worth finding a syntax to express it.

.box {
    border: 1px solid gray;
    color: red; // would cause text in the header to be red, but not inside the body.
    scope: start; 
    & .hd {
        border-bottom: 1px solid gray;
    } 
    & .bd {
        scope: end;
    }
}

This basically says that hd and bd belong to the box object and that the scope of these styles starts at .box and ends at .bd. It prevents styles from bleeding either up or down. Note: I do wonder if we need to say where it starts given that the nature of CSS is that it is namespaced to wherever the selector begins. It also makes me wonder why in the world scope is in the HTML rather than the CSS. It seems oddly out of place. Moving on…

There are several ways to mark up tabs, but let’s assume the HTML of the tabs component looks like this:

<div class="box tabs"> 
    <div class="hd">
        <ul class="tabControl">
            <li><a href="#">Personal</a></li>
            <li><a href="#">Date & Time</a></li>
            <li class="current"><a href="#">Password</a></li>
            <li><a href="#">API</a></li>
            <li><a href="#">Timer</a></li>
            <li><a href="#">Rounding</a></li>
        </ul>
    </div>
    <div class="bd">
        <ul>
            <li class="tab-bd">Tab 1 Content</li>
            <li class="tab-bd">Tab 2 Content</li>
            <li class="tab-bd current">Tab 3 Content</li>
            <li class="tab-bd">Tab 4 Content</li>
            <li class="tab-bd">Tab 5 Content</li>
            <li class="tab-bd">Tab 6 Content</li>
        </ul>
    </div>
</div>

What you can see is that tabs are an extension of an ordinary box. They have a head and body wrapped in a div with the classes box and tabs. What makes the tabs unique is that both the head and body are filled with unordered lists which correspond to the tab control and tab body respectively.

Tabs with the donut highlighted
Figure 2: Tabs with the donut highlighted. We don’t want any styles falling either into the donut hole. This where scope ends. (See? It’s donut colored! Forgive me, this diagram is very very ugly.)

We could try to express the next bit by combining three tools:

  • nesting for defining the component structure,
  • extends so we don’t need to repeat anything we already know about boxes in the code for tabs, and
  • a new property “scope” which tells the browser where to stop allowing styles to bleed down.
.tab {
    extends: .box; // so inherits the starting scope 
    & .tab-bd {
        scope: end;
    }
}

So, any styles for tabs should only apply to the nodes between the start and end of scope, or between .box and .tab-bd. Is this the right syntax? I’m not sure actually, but I tend to like it.

The region we want to apply styles to.
Figure 3: the region we want styles to apply to.

Figure 3 sums up what I’m asking for — a way to apply styles only to the divs which make up my object and not to content that simply happens to be inside it. You can do that today with careful use of style and the child selector “>”, but in a world where some content is trusted more than other content, it might be easier to just be able to say explicitly which donut of elements I want a particular set of styles to apply to.

You may have heard the Henry Ford quote:

If I’d asked customers what they wanted, they would have said “a faster horse”.

Henry Ford

I think lots of us want *way* more than just a faster horse. :)

What do you think? Useful? I’ve been holding on to this post for four months because I wasn’t sure about it, because it is quite different from how things work now, but I thought I’d put it out there and see what other people think.

Don’t Style Headings Using HTML5 Sections

Styling headings is either a deceptively complex problem, or maybe the design of CSS made it appear complex when it need not have done.

When styling headings (or really anything) we want three big goals to be met:

  1. DRY – Do not repeat yourself. We want to set headings once and never (ok, rarely!) repeat those font styles or selectors. This will make our site easier to maintain.
  2. Predictable – The heading should look the same no matter where on the page it is placed. This will make creating new pages and content easier.
  3. Keep specificity low and selectors as simple as possible. This will help with performance and keep the site from growing more and more tangled over time.

The html5 section tag is weird. It dramatically changes the way we use headings. It also changes the way browsers and assistive technologies are meant to interpret those headings. The spec says:

“The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.”
The HTML5 Spec

The spec goes on to warn us that sections are not really meant to be used just because you want to attach a style a particular piece of content:

“The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead. A general rule is that the section element is appropriate only if the element’s contents would be listed explicitly in the document’s outline.”
The HTML5 Spec

People seem to have blocked out this last (very important) bit, so I’ll reiterate. Sections aren’t really meant to be used by CSS for style purposes (at least not *only* for styles). So, if sections aren’t meant to be used to make my headings purty, why do they exist? They change the way the browser and assistive technologies interpret the importance of a heading relative to the other headings on the page. To understand this, you need to know a bit about the pitfalls of the way headings have been written up until now.

HTML Headings

Think back to the outlines you wrote for term papers in high school. Each bit of a website is meant to be like that, each heading corresponds to a piece of that outline, and you know when you go up or down a level by the heading level chosen. H2 is down one level from H1. And h6 is down four levels from H2.

THE TITLE IS THE H1
I. Big roman numerals are the H2s
   A. This is an h3
   B. This is also and h3
      i. Now we have an h4
      ii. And another h4
II. Big roman numerals are the H2s
III. Big roman numerals are the H2s
IV. Big roman numerals are the H2s

The trouble is, on a modern website or web app, this model isn’t a really natural fit. Especially if a site “mashes up” content from sources they don’t control (say for example adding a twitter feed to a blog), they may not be able to set the heading levels used by the mashup content. In this case, most developers, just include the new content, and the outline gets a little murkier.

A murky outline may be somewhat normal, because I’d take it a step further and say that, on most modern websites, the idea that the site has much in common with a high school term paper outline is a bit of a stretch — The section element tries to bridge the gap between the w3c’s outline view of the web and the way developers are really building sites. The section element essentially reorders the heading tree so that whatever headings are used, if they are wrapped in a section element, they will be made to fit in with other content on the page. They need only be internally consistent within each section.

<h2>Me on the web...</h2>
<h1>My Twitter Feed</h1>
<ul class="tweets">
 <li>Mmmm, cornflakes.</li>
 <li>Something inane...</li> 
</ul>
<p><a href="more.html">More stuff on the web</a></p>

HTML5 Headings & Section Elements

If you wrap it in a section, the browser will interpret it as one level down from it’s parent heading.

<h2>Me on the web...</h2>
<section>
<h1>My Twitter Feed</h1>
<ul class="tweets">
 <li>Mmmm, cornflakes.</li>
 <li>Something inane...</li> 
</ul>
</section>
<p><a href="more.html">More stuff on the web</a></p>

The section element also makes it clear that the list of tweets belongs to the Twitter feed, and the more link does not. This makes content more portable, which is okay — even if it maybe isn’t that important. However, it does seem to be confusing people about how they should style their headings. I think this bit of the spec might be confusing people:

Notice how the use of section means that the author can use h1 elements throughout, without having to worry about whether a particular section is at the top level, the second level, the third level, and so on.
The HTML5 Spec

This has lead people to think that they should only ever use h1s (which, is a fair interpretation of the working group’s note). However, lots of people have taken it a little too far because they didn’t read the second quote [1], where it says additional section elements shouldn’t really be used only to apply CSS styles. Admittedly a subtle difference, but important! Section elements are meant to help the browser figure out what level the heading really is, but not necessarily to decide how to style it. By tying styles to browser heading level interpretation, developers (trying to implement html5 from the spec) are ending up with selectors that look like this:

h1{font-size: 36px}
section h1{font-size: 28px}
section section h1{font-size: 22px}
section section section h1{font-size: 18px}
section section section section h1{font-size: 16px}
section section section section section h1{font-size: 14px}
section section section section section section h1{font-size: 13px}
section section section section section section section h1{font-size: 11px}

(Note: This is vastly simplified as I’ve only included sections and not the other sectioning elements like articles or asides. This is a more realistic, real life code sample.)

Let’s see how well this meets our goals:

Q: What if, semantically speaking, you need to add an additional section to a bit of html?

It will unintentionally change the way your headings look. If it is high enough on the document tree it could change your entire page. That seems badly unpredictable.

Q: What happens if the design calls for a 14px heading in a part of the site that is only nested two sectioning contents deep?

To make it work with the existing code, you would need to add additional unnecessary section elements. The spec pretty clearly states that section elements are not meant to be added just to change styles. Plus, that is just kind of gross.

Q: What if we create another rule that duplicates the 14px property value pair?

section.special section h1 {font-size:14px}

This clearly isn’t DRY. We’re repeating the code to set the font-size to 14px, and our specificity is starting to get weird. If we want a normal two-section deep heading (22px) we now can’t have it in the special section. We also can’t reuse the new rule anywhere else. Continue in this direction for a while on a project and you can end up with hundreds or even thousands of heading declarations. Eek! This isn’t meeting our stated goals at all.

(For more info about how this can get out of control, check out this video on how our current methods for styling headings are leading to bad outcomes.)

So, how do we style headings in an HTML5 world?

The answer is right there in the spec, next to the place where we learned to use only H1s. We shouldn’t use sectioning elements for styling. We should let them do the job they were designed for, which is sorting out the document tree, and solve styling issues another way that meets our goals better: with simple reusable class names that can be applied to any of our headings no matter how deep they may be in the sectioning content.

I recommend abstracting site wide headings into classes because then they are portable, predictable, and dry. You can call them anything you like. Jeremy Keith recommends something like:

.Alpha {}
.Beta {} 
.Gamma {} 
.Delta {} 
.Epsilon {} 
.Zeta {} 

or

.tera {} 
.giga {} 
.mega {} 
.kilo {} 
.hecto {} 
.deca {} 
.deci {} 
.centi {} 
.milli {} 
.micro {} 
.nano {} 
.pico {} 

I keep it simple with:

.h1{} 
.h2{} 
.h3{} 
.h4{} 
.h5{} 
.h6{} 

It doesn’t really matter what system you choose as long as it is something easy for your team to remember. Then, no matter how many section levels deep your heading is nested, you can make it look just how you want:

<h1 class="giga">Me on the web...</h1>
<section>
  <h1 class="kilo">My Twitter Feed</h1>
  <ul class="tweets">
    <li>Mmmm, cornflakes.</li>
    <li>Something inane...</li>
  </ul>
</section>
<p><a href="more.html">More stuff on the web</a></p>

So now, your twitter feed, from the previous example, can be in the sidebar on an article page, or in the footer of your homepage, and it will still look the way it was designed to. Whether you are using html5 sections or not, you don’t want to repeat code or have it be unpredictable, so I think separating styles from how the browser generates the page outline is just sensible.

UPDATE 9/6: If you truly cannot change the HTML, even to add class names, then the only way to style that bit is to put a wrapper around it with a unique class and use descendent selectors to force the style you want. This should be the exception, not the rule! (Thanks Simon for pointing out that I wasn’t addressing one of the use cases I had talked about above)

<h1 class="giga">Me on the web...</h1>
<section class="tweetfeed">
  <h1>My Twitter Feed</h1>
  <ul class="tweets">
    <li>Mmmm, cornflakes.</li>
    <li>Something inane...</li>
  </ul>
</section>
<p><a href="more.html">More stuff on the web</a></p>

If you would like a far more eloquent walk through all the new html5 elements, get Jeremy Keith’s book HTML5 For Web Designers.

Thanks to Alex Kessinger and Josh for helping me solidify my thoughts around this by bringing up good questions on the CSS Lint Google Group.

Our (CSS) Best Practices Are Killing US

Another day, another melodramatic blog post title. ;)

I was prepping to speak at Webstock this year when I realized I didn’t want to give the talk I had proposed. I didn’t want to talk about the Mistakes of Massive CSS, because I realized it went deeper than that. In fact, in most cases, the things we considered best practices were leading to the bad outcomes we sought to avoid. I realized (unpopular though it might be), that we couldn’t make it work out well by trying harder. Each time we start a new project, we think “this time, I’m going to keep the code clean. This time the project will be a shining example of what can be done with CSS.” And without fail, over time, as more content and features are added to the site, the code becomes a spaghetti tangle of duplication and unpredictability.

It is time to let ourselves off the hook. There is nothing we could have done by trying harder. There is no magic juju that some other developer has that we don’t. Following our beloved best practices leads to bad outcomes every. single. time.

What are those flawed best practices?

  • Classitis!
  • Never add an non-semantic element
  • Or, a non-semantic class
  • Use descendant selectors exclusively
  • Sites need to look exactly the same in every browser

Here is the video of my talk at Webstock 2011:

Classitis!

How in the world did we even get the idea that some aspects of CSS were good and others evil? Who decided and what data did they use to judge? Did their goals fit our goals? There is nothing wrong with using classes. In almost every case, classes work well and have fewer unintended consequences than either IDs or element selectors.

You should style almost everything with classes. The goal is to find a balance between classes that are too broad and include everything and the kitchen sink and classes that are too narrow. Generally speaking, you don’t want your classes to be so narrow that each one applies a single property value pair. It becomes extremely hard to evolve your design if every item is composed of mini-mixins.

On the other hand, if classes are too broad, you will have duplication. Try to find the middle ground where all the repeating visual patterns can be abstracted. This is hard, but very worthwhile. If you do it, your code will stay clean. You will finally see results from trying harder.

Classes are our friends. Seeing a lot of IDs is actually very bad. Run from this kind of code:

#sidebar #accounts #accountDetails h3{}

Never add non semantic elements

We don’t want to have unnecessarily heavy HTML with a lot of extra elements. On the other hand, adding an extra element can often provide a buffer between two sets of classes that weren’t necessarily coded to interact with one another. For example, I prefer to have the decorative elements of a container completely separated from its content.

Using a paragraph that happens to be inside a rounded corner box to make a corner decoration means that the container can never hold content other than a paragraph. If you want to include a UL you will need to duplicate all those styles. This doesn’t work.

You want your content to be marked up in beautiful HTML that uses a diverse set of tags like P, UL, OL, LI, H1-6, strong, em. Add a few extra wrapper elements to keep your content nicely cordoned off from your containers or separate out decorative flourishes! Your HTML will be clean and your CSS predictable.

Never add non-semantic classes

We absolutely don’t ever want to use classes like “bigRedHeading”, not because it is non-semantic, but because it isn’t future proof. As the design evolves, the CSS needs to keep pace. On the other hand, CSS needs abstractions. We need to be able to solve a particular problem really well, and then allow people to go on using that solution long afterward. Grids for example solve the layout problem. Once they have been implemented on a site, developers can spend time on more important features and stop re-implementing a layout solution over and over. Abstract solutions are necessarily disconnected from the content they happen to contain. This is something we should look for in a solution, not condemn.

The semantics debate has really gone too far. It is useful as a general principal, but often I see standards aware developers trying to stuff in semantics that never existed in the design. If the design didn’t make a distinction between two things visually, why add additional complexity? Classes work much better when we use them to represent visual semantics, rather than keeping them tied to content.

One more point on the topic. Screen readers don’t read class names. It is not an accessibility issue. (Thanks to John Foliot for confirming)

Use descendant selectors exclusively

Never has more terrible advice been given (ok, ok, I exaggerate, but for CSS, this is as bad as it gets). The descendent selector is *only* appropriate between multiple nodes of the same object (say, a tab container and its’ tabs), and even then, only when you are absolutely certain that there will never be any markup changes. Very hard to guarantee, no?

I have had a designer give me a tab container that had one group of tabs to the left and another grouping (usually more simply styled) to the right. In which case, if you had styled the UL using the descendant selector, you would be stuck overriding a bunch of styles you no longer needed. Classes are much much better and can be used in combination with the descendant selector when the nodes belong to the same object.

I guess the only time I use the descendant selector with elements is to style LI, and even then, I often get bitten when someone wants to nest those lists. Better support for the child selector will make that issue easier to fix. Ideally, we don’t want any styles flowing from container to content.

Even with the media block, you might consider putting a class on the media block which sets the styles of the image. It sounds reasonable until you realize that the image is actually its own object. You might have multiple nested media blocks and you will get very weird interactions unless you apply the image style class directly to the image itself.

In the middle layer, you might decide to create one display objects for each of the different types, and that would probably make the objects easier to use, but in the CSS layer, you don’t want to tie it all together like that.

Sites need to look exactly the same in every browser

Forking your design is bad, it makes testing even more complicated, but that doesn’t mean that pixel for pixel a site needs to be exactly the same in every browser. If you try to force the complexities of a modern design onto users of IE6, their user experience will suffer. The site will load slower and reflows and repaints will make the javascript sluggish. IE6 users need a reasonably fast user experience, they do not *need* rounded corners.

Anyway, enough ranting. Please do checkout the slides and video. I hope you find them useful.

Performance Double Whammy Hits New Zealand at Webstock

Interested in Performance and scaling sites to a large number of visitors or pages? I just realized both Steve Souders and I will be giving talks at Webstock next week! This is a pretty amazing opportunity to massively increase your Performance mojo in one go. :)

I’m going to be hosting a workshop in which you will learn to build your own site using OOCSS techniques. By the time you leave you will have the skills necessary to write efficient, scalable CSS. You’ll understand the joy and pain of CSS3 and HTML5, and be ready to go build the next generation of websites and web apps.

Steve’s workshop is filled with Mobile yummy goodness. How do you figure out that your mobile app is slow before your clients start complaining? What’s even going on in there? In his workshop, Steve is going to open up the mobile black-box and teach you to take a peek inside.

I am super excited about Webstock, even more so now that I found out it will be a perf-geek-meet-up. New Zealand here I come!

Grids improve site performance

CSS grids can improve performance? How so?

The Importance of Page Weight

The weightier your page the slower the user experience. There are a few notable ways you can ease this correlation, but for the most part keeping your pages snappy is about being absolutely relentless when reducing and optimizing code. CSS is no exception.

On the other hand, a blank white page with unstyled black text and blue links would be very fast — but no one would care to visit. When we accept that we want sites which are both graphically interesting and fast we can begin to find ways to achieve what I think of as a one to many relationship between the amount of CSS we write and the potential layouts we can achieve.

The cure for bloat

Finding common denominators in our site will allow us to standardize the way we group related content, and the classes we use to style that content. You can think of these common denominators as the semantic building blocks of a high performance website. On a basic level that means that most sites have a particular way of displaying, for instance, a product. Perhaps with an image of the product to the left and a description of the product to the right. If that configuration appears throughout the site it should not be rewritten each time or we’ll have a 1:1 correlation between the size of the CSS and the complexity or number of pages in the site. These are the kind of sites that might start off fast but over the course of their lifetime become slower and slower. Once clean CSS becomes bloated with unnecessary recoding of semantically and visually identical elements.

Where do grids fit into the mix?

Grids are one of the simplest examples (to see, not to code) of patterns that can be abstracted across a site. The same basic three unit pattern which divides grouped content into three semantically linked chunks can be seen inside the main column content and also inside a module, defining different groups of content. In the next two pictures, I’ve outlined in orange the same grid being used two ways. Not coding this again and again is a huge performance win when multiplied over all the components and pages of a large site.

Image 1: Grids can be used to define the structure of the main column of a page.
Grids Macro

Image 2: The same grids being used to break up the content within the body of a module.
Grids Micro

It’s easy to see each piece of your site as a one-off, unique, something which will never vary — but performance dictates that we take a more sage approach. We need to abstract objects, the simple building blocks of your pages. The objects can then be combined to create pages and the pages combined to create entire sites.

Do not reinvent the wheel, grasshopper (at least not for a major client)

You may be tempted to write your own grids framework rather than use one that is already out there. The not invented here mentality is really hard to get around. If you really can’t resist the urge to write your own grids, do it for your blog, not a major international company. It’s a fun exercise, but the pitfalls are treacherous.

The Requirements & Constraints

  • Grids and units can be nested inside each other to achieve complex layouts. The logic is very simple; any grid can be nested inside any other. Keeping constraints low simplifies CMS development. You should not need to write any additional CSS to make this possible or you start getting n! css rules. Yes, this is bad.
  • Each unit controls it’s own destiny, uh, width that is. In CMS design, one of the most costly operations is when you need to make changes elsewhere in the DOM in order to generate display or behavior in the current location. Keep all the classes necessary for the unit to function on the unit itself. This will make page building much quicker and code easier to navigate.
  • Unit width can be any fraction of the total width. Generally I create fractions up to fifths, more than that is probably overkill.
  • Fewer templates. Templates are unique starting points for building pages. They complicate using a CMS because generally they aren’t designed so that you can go from one to another easily. Developers love to create new templates, while CMS users hate them. Try to refrain.
  • No JS required. Using JS for basic layout is wasteful. We need JS to do other important things, thus we need to solve layout problems with CSS.

Redefining the template

Traditionally, a new template is created for each page type. Separate templates might be defined for one column, two column, and three column layouts, as well as home pages, main product pages, etc. Grids allow you to base all of these pages on the same template, which might include only the basic frame, header, body and footer. The template stays simple because grids allow you to break up any one of these regions into convenient units of content. You should then include a “save as a template” option. Your users can then define templates as they build pages in your CMS, saving at convenient points from which they can build pages. Having a common starting point, or one single base template will mean that users can undo any choice they’ve made.

More about templates in another article.

Grids solutions

So now that you know a bit more about how to choose a grids solution, go check out these frameworks to find the one that will work for you:

nest Size (kb) fixed or liquid columns units License gutter
Blueprint No 7.2 fixed 24 30px GPL 10px
960s No 5.4 fixed 12 & 16 40 & 60px GPL 20px
YUI2 No 2.8 liquid 1 to 3 1/2 1/3 BSD 1-4%
OOCSS Yes 0.7 liquid 1 to 5 1/2 1/3 1/4 1/5 BSD 0px
YUI3 Yes 1.5 liquid 1 to 24 1/2 1/3 1/4 1/5 1/6 1/7 1/8 1/12 1/24 BSD 10px*

* YUI3 requires an extra sub-node wrapper for the gutter.

Any other grids frameworks I should have included?

Note: I wrote most of this article years ago, but never got around to publishing it because it wasn’t “perfect”. (Oh how annoying it can be to be me). If you notice anything out-of-date, please do bring it to my attention.