Blueprint.css: You’re Just Fooling Yourself.
Blueprint.css is a “css framework” which makes it easy for you to lay out your page with however many columns you like, without even looking at the css. It works by instituting a 950px wide container around your page, and then dividing this into 24 columns. You can add a ’span-x’ class to any div to make it span x columns.
The Good
Blueprint makes it really, really easy to add columns to your page. You just decide how many columns you want the area to span, and add that class (keeping in mind to add the ‘last’ class to the last element in a row).
Blueprint also sets many sensible options for line spacing, fonts (arial), lists, and other things, making the defaults a bit prettier. It also includes an ie.css file of its own, to include in your page to correct some IE bugs, which is convenient.
The Bad
Blueprint marries you to a 950px fixed-width layout, which may or may not be ok with you.
I did notice one IE bug where list elements in an <ol> had the numbers cut off, which a client complained about. It just needed a bit of extra left margin is all.
The Ugly
The real evil of blueprint.css is that it tricks you into thinking you’re being a good designer, seperating content and behavior and layout in html, js and css like a good designer should. However, all the column-defining classes live in the HTML, and have names with no semantic meaning; just, ’span-24.’ In reality, blueprint.css is table-based design with a different syntax.
If you were to do the right thing, and call the left sidebar ‘left-sidebar,’ the content ‘content,’ the header ‘header,’ and the menu ‘menu,’ you could reorganize everything without having to change any HTML, which is doubleplusgood if you have a lot of pages to change.
Instead, in a few years, when you want to redesign your site, you’re going to have to change each of the elements you told to span-x to either span something different, or remove it.
I know it seems easy now, but so do tables. Do the right thing, and you’ll be happier later.
I’ll keep using blueprint though, I do my separation using PHP. Thanks, blueprint guys!
Fuel another post
August 10th, 2008 at 9:03 pm
Hey, Adam!
I’ve been searching for a css framework to use in some of my newer projects. I reviewed Blueprint among others, but ended up using 960 Grid, http://960.gs. Idea is pretty much the same, documentation is very simple and easy to read, and author provides several nice templates for printing, or for software like Photoshop, OmniGraffle, etc.
Since I needed to style every element on the page, what I ended up doing is adding extra class & comments to every 960grid-defined element. So the code looks like the following:
…
…
Which in my opinion is perfectly fine when it comes to maintaining this code in the feature.
Your other argument, the 950px fixed layout - well, for majority of the stuff I end up doing that seems fine. It is 960 pixels in Grid960, hence framework’s name :) It very well might turn out to be problematic for some, no arguing about that.
But really, this argument regarding the code being hard to read if grid-based frameworks are used really comes up again and again, all over the blogs and forums. But is it so hard to put comments in your code, for your sanity’s sake? Also, you’ll end up styling your divs at some point, so wouldn’t that solve the problem of not having proper class names?
August 10th, 2008 at 9:07 pm
Sorry about missing HTML code. You can view it here: http://dpaste.com/hold/70572/
August 10th, 2008 at 11:16 pm
I admit I do use css frameworks from time to time, but when I do I like to put the header, nav, footer etc. designations in as ids, instead of classes. That way, I know that styles I apply to #header and so on won’t be overridden by the framework.
The real problem isn’t when you first make the page, but when you (or someone else) want to go back and change it. Imagine having 30 or more HTML pages comprising your site, that you wanted to change from having left sidebar width of 6, to 7? Sure, you could just change #left-sidebar, but then you’re left with a completely useless class name.
I don’t care about code being hard to read, like you said there are always ways to improve that. It just seems to me that putting layout cues in the markup goes against the whole reason why people ditched table-based design for css layouts anyhow.