Blueprint Vs. 960

January 11, 2009 - 8:51pm

The starter guide in my last entry practically gives you an intro to the 960 framework as well. The names are different, but the approach is the same. Though 960 is a bit more complex. .container-x, and both "first" and "last" classes (named alpha, omega, pretentiously enough).

I decided to checkup on a drupal groups thread that discussed CSS frameworks AFTER I hit publish. As it turns out, a 960 theme is on its way to drupal core.

I think 960 is a fine system, and I also think CSS frameworks are still *new* enough of an idea that we don't need to put all our marbles in one (like we did with jQuery -- and thank god we did [Konstantin Kaefer, thanks you for not listening to me in GSOC, when I told you to consider working within Drupal's GPL requirements.].

I think its great that we're moving to get a framework into drupal, and 960 may be the one. Given my history with the whole jQuery thing, I can't ask that you take my preference of blueprint THAT seriously. BUT....

960 vs Blueprint

  • Blueprint is simpler: I like that blueprint's containers never change. I don't need either a grid of 12, or a grid of 16. 24 works fine for me. There's also only a "last" class, as opposed to 960's "alpha", and "omega"'s. What's the difference between grid-6, and container-6? Can grid-14 fit two container-7? I'm too lazy to look up the answer since I've never once run into a problem where blueprints system wasn't as flexible as I needed. Especially since the designer and I work together, and we tend hold off on the design until we have all the content.
  • Blueprint gives a damn about typography: 960's creator says says "I haven’t gone out of my way to establish a vertical rhythm for text, as is described in the Baseline article on ALA. It’s not that I don’t see the value in it, I do. I think it’s an awesome idea, and a noble pursuit. However, it is fragile. All it takes is for a content editor to upload an arbitrarily sized, 173 pixel tall image, and all the subsequent elements are off-beat." I fail to see what I gain from losing this feature in blueprint. Especially given I use imagecache, and know exactly what to do when an image is 173 tall: fix it.
  • Blueprint has a community of active contributors, and the frameworks is evolving quite noticeably: 960 appears to be the work of one guy.

Now, mathematically, it can be argued that 960 is superior in terms freedom (12, and 16 have quite different properties). However, I think that freedom can be a bad thing. In fact, it opens the door to the dreaded inner platform effect -- where a framework becomes a poor replica of the language it intended to replace.

Overall, I think getting 960 into drupal core is a big win. I've yet to find a reason to use 960 instead of blueprint, but who knows... maybe we'll give 960 a jolt that makes it the jQuery of CSS. In any case, Drupal is ahead of the pack in recognizing that value of a CSS framework over the standard/semantic inquisitions who are apparently too busy blogging, and boring audiences at web conferences to understand the clear gain that comes at the small cost of having a class named "span-6". (what is the cost, exactly? the bytes? or that I don't have to look up a stylesheet to see what's going on?")

This is particularly true with Drupal. Lots of sites we build already have 16 different .tpl.php files between all the views we're using. I actually prefer a bit of presentation in my markup in these cases. Not mention, with the slew of classes like "views-row-odd views-row-first views-row-1" already in the markup, "span-2" seems like a pebble in the sea.