August 6th, 2007
Olav Bjorkoy has come up with a lightweight CSS framework called Blueprint (via Daring Fireball). The framework is intended to be a starting point for your own projects, providing basic typography, a print stylesheet, and a grid structure for your page layouts.
Blueprint is a great idea, and my initial impression is that Bjorkoy has done an impressive job at making a flexible framework with a very small amount of code (the entire expanded download is under 40kB).
My only reservation is that the method for implementing the framework in a website is a little too reminiscent of using tables for layout purposes. For instance, one of the bits of sample code:
<div class="container"> <div class="column span-14"> Header </div> <div class="column span-3 first"> Left sidebar </div> <div class="column span-8"> Main content </div> <div class="column span-3 last"> Right sidebar </div> </div>
Rather than marking up the content semantically, the classes used are related to the desired layout, specifying the width of the content (“colspan” from the old table-laden days being the obvious parallel).
Ideally, class names should reference “what” the piece of content is – navigation, footer, etc. – rather than what the content should look like. Combine the content and the presentation, and at best you have classes that make no sense when you redesign the look of your site. At worst, rather than just recoding your CSS, you end up needing to recode your CSS and your XHTML to implement a redesign. Many web developers will find the content and presentation getting much too cozy in the above example. It’s a step backwards from the direction in which XHTML and CSS have been heading.
I can see why Blueprint works this way of course. Since it needs to be generalized in order to be used in all types of projects, there’s no way to know what sort of semantic structure the XHTML may have. To keep it that general, the layout itself is really the only thing you can sensibly use for class names, as unfortunate as that may be.
Of course, Blueprint is still a work in progress, so hopefully Bjorkoy or one of the framework’s users might come up with some way of de-tangling the content and presentation a bit. Two possibilities came to mind, though I’m not sure how feasible they may be:
1. Some sort of intermediary between the XHTML and the CSS. If there was some way perhaps to use Javascript to dynamically add classes to elements on the page, a developer could code semantically, and then add Blueprint’s layout-based classes on the fly. This would be an extra step, but at least the layout-based markup wouldn’t be hard-coded into the content.
One of the comments at Bjorkoy’s blog suggests using Prototype to do something similar. I really don’t know how workable this would be, but it could be worth looking into.
2. Cut and paste. Another option would be to code semantically, add your content-based class selectors into the CSS, and then copy and paste the specific layout-based Blueprint properties and values into your own CSS definitions – essentially using the Blueprint CSS definitions as code snippets. Since Blueprint is so streamlined, this would probably be relatively easy – in many cases it would be nothing more than something like “margin-left: 0; width: 400px;”.
For instance, returning to the code above, rather than using this:
<div class="column span-3 first"> Left sidebar </div>
One might code this:
<div class="column navbar"> Left sidebar </div>
And then add this to the CSS:
.navbar { margin-left: 0; width: 190px; }
In that last bit, “margin-left: 0;” comes from Blueprint’s definition for “.first” and “width: 190px;” comes from Blueprint’s definition for “.span-3″.
The downside to this is that if you decide to change the column width that your grid is based on, you’ll need to edit those widths in more places within the CSS. No matter what, it seems at this point that there has to be a tradeoff somewhere – in this instance you’re trading a more easily updated grid for more semantic markup.
Despite this, Blueprint looks like a great start, and it’ll be interesting to see where it goes as it’s developed further.

August 6th, 2007 at 6:31 pm
You are of course completely right, but I’m not quite sure how to best name the class names when dealing with a framework like this.. We’ll see.
Hope you’ll find it useful!
August 6th, 2007 at 9:42 pm
Hi Olav … thanks for stopping by and commenting. I definitely think what you’ve done is useful, and I’m hoping to have a chance to try it out on an actual project at some point. Like I said, I can totally understand why you named the classes as you did. I can’t really imagine what other sort of naming convention you could use that would be semantic yet still as flexible and generalized as what you’ve done. At any rate, nice work on it, and good luck moving forward!