Blueprint Vs. 960

01.12.2009

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.

Comments

after pondering quite a bit

after pondering quite a bit why alpha and omega were used...

the guys behind 960 seems to be a very religious person, so I'm guessing it made sense to him or thats what just came up in his mind (BTW I'm not implying anything is wrong with this)

As one of the guys actually

As one of the guys actually working on the grid 960 theme, I thought I'd pipe up and mention that the group has played pretty extensively (even going so far as to extrapolate it out to a fluid width theme). There are many good points here about how much this has (or hasn't) been tested, however, cross browser compatibility isn't enormously difficult, so even if there are issues (which thus far there hasn't been) fixing them will probably move more quickly given the state of the framework. In addition to this, the relative smallness in size means that some of our suggestions to making the framework better (css to allow content first layouts in the grid) also move significantly faster.

In any case, it's really great to hear this feed back, and I hope to see a 6.x contrib theme before February and this should go a LONG way towards getting the sort of feed back we really need for the framework in general.

I can tell you I've personally done quite a bit of work to get many of the features that we love from zen and basic ported over into a starter kit style theme for Drupal. Again, I hope this will really help to push the framework along at a much more rapid pace than we might be able to do with other more established frameworks.

I look forward to the feedback.

Eclipse

As someone who made one of

As someone who made one of the first Drupal css framework themes (based on YUI, something that I may stick with after checking out the others), I have to say that it's a bit funky that a new core theme could end up being one of the most untested ones out there.

There's existing Drupal YUI themes, and existing Blueprint themes, but no 960 themes that I could find. Going with the 'maverick' choice for the CSS framework seems somewhat counter to the whole concept of using a a grid framework in the first place. ;-)

*unless you want them to* "I

*unless you want them to*
"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."
Have you RTM? Do take a look in the lib folder, particularly at compress.rb and settings.example.yml and read the documentation about them (might be on the blueprint wiki iirc). This flexibility is what makes blueprint stand out IMO, not that it's 'fixed', way too many people seem to take blueprint as static css files without looking deeper.

Just before xmas I started playing with Blueprint myself, and am currently using it in a custom theme (both the library and the drupal theme).

I know that is not the

I know that is not the discussion about Emastic but I just want to say few words. Emastic is build to improve usability, it's em based (ctrl +) and everything will resize, it's 4kb + plugins and the most important can implement nested divs(you can put 500px div in 500px div or 2X250px). Optional you can use the grid based on % and grid based on absolute positioning or you can mixx everything. I thing that emastic is perfect for template makers or for the systems like Drupal, Joomla because everything is modular and you have three grid systems in one. The last thing are the fluid columns, if you need fluid layout you can use them.

@Nick: I personally prefer static layouts because I have major control over the layout, but there are many who still prefer fluid or semi fluid it is probably personal decision.

I'm sure you may have seen it

I'm sure you may have seen it already but there is a Blueprint theme that is actively being developed.

http://drupal.org/project/blueprint

BTW, that video of Benjamin

BTW, that video of Benjamin Zander is awesome:
http://brenthardinge.net/blog/give-them

My favorite line:
"That's the only reason to practice: we want make the notes so beautiful that people care what happened to them."

*Now I'm gonna go play some Chopin.

ya, my previous post mentions

ya, my previous post mentions it in headers. I'm using it as the base on 6 projects atm.

Maybe it will be Emastic,

Maybe it will be Emastic, which is evolving quickly.
For blueprint I think the only limitation is fluid layout, well you can expand on the tags, but it still feel 'crippled'.

I've always felt like a

I've always felt like a layout that HAD to be fluid was a bad layout, and a designer who's first priority was for it to be fluid had the wrong priorities (there's a LOT of costs, design wise).

Fluid layouts, for example, have a way of making text really hard to read on big monitors. Cellphones won't necessarily benefit from them either (in fact, god forbid: the layout is so fluid that it tries to fit a 3-column fluid in a cellphone). What's the gain? I've never understood it. Really. Never. Never once have i been able to understand why fluid layouts are anything but a bad idea. I feel like they fail on so many levels: a design, technical, and where are you going to spend your limited time/effort perspective.

Fixed width designs are a

Fixed width designs are a remnant of an earlier, printing world. They are obviously more mature, due to the thousands of years of bookmaking, and thus conceptually simpler to implement than something that needs to take proper advantage of differently sized screens.

Fixed width designs fail to take advantage of the new medium properly. They are a reactionary conservative gesture against the change that Internet viewing ports we call monitors have wrought on the entire field of design.

The "perfect" fixed width designs are still inherently regressive and weak, and should be culled from the flock. "Perfect" fluid width designs (though harder to achieve) are beautiful and true to the world they live in.

Personally I prefer fixed

Personally I prefer fixed layout as you'll have more control, or semi-fluid where there is min/max width defined. So the problem of going overboard on big monitor etc does not occur.

But fluid layout has its place to make full use of the full screen real estate. Take current Drupal.org theme and GMail as example, fluid layout make the pages not cluttered as there are a lot of info going around.

On CSS grid, one annoyance is the size inheritance. Says you modify the parent div span-x, all children div span-x have to be readjusted.