In Defense of CSS Grid Frameworks
Jun 26, 2009 In Design By Nishant KotharyCSS grid frameworks seem to have a pretty tarnished image as far as philosophical topics in front-end web development go. One quick search will reap a plethora of blog posts and articles on the topic. If you have a limited amount of time to get caught up on the controversy, I recommend that you read this, this, this, and finally, this.
For those of us who don’t really have the time or resources to take the plunge with a framework so as to form our own opinions, we usually pick the safer option: not using a grid framework. That's pretty much the only option I've picked in the past, but it's proven to be a sub-optimal one since I always end up creating a grid or a set of grids depending on number of layout templates for the site. What's more is that these share common characteristics (such as column count, gutter width, etc.) that I eventually abstract out under semantic class names (e.g. features_sidebar, main_content, etc.); dare I say, I end up creating a framework for layout? There are a slew of problems related to maintenance and extensibility with the approach of adding layout attributes in these semantic classes, but I'll spare you the details. Suffice to say, I've marked up enough sites over the years to remain frustrated with the approach of carefully building a layout from scratch purely because it’s a matter of pride. I'm with Ranae on this one.
Some developers treat it as a matter of personal pride to carefully build every layout from scratch — even if it means they're doing the same repetitive tasks over and over again. For my part, I treat it as a matter of pride to find ways to work smarter and be home in time for dinner.
Lately, I've had the opportunity to mark up a couple of small sites using a pretty popular framework, 960.gs, and a lesser known one, 1kbgrid. They're very lightweight (well, 1kb is obviously minuscule) and do one thing and only one thing really well: grid layout. In fact, if I were ever to abstract out the layout framework for my sites, I'd probably end up with something pretty close to either of these frameworks. Needless to say, I'm quickly becoming a fan of simple, elegant frameworks like 960 and 1kb especially in light of MIX Online's future needs, and the semantic trade-offs are starting to seem well worth what we get back in maintainability, consistency and clarity. I'd argue that the "grid_4" or "column" are pretty semantic class names, and a difference of opinion there is really just, well, semantics, but let's not start a bar brawl over that just yet. Click on the screenshot below to be taken to a little one-page site I built as the front for my personal domain, Rainypixels, and then view source. The code validates and meets my acceptance bar as far as semantics are concerned. If you have a different opinion on that, I'd love to hear it.
We're going to be launching a new issue here pretty soon, and we recently made a decision to decouple our lab sites from the core MIX Online experience. Right now are labs are just individual pages within the MIX Online chrome and that presents some challenges as our labs get bigger and start warranting multi-page sites. Decoupling, however, introduces the converse problem: we now have to build a fully functional, potentially visually unique web site every time we launch a new lab, and this site needs to feel like it's a part of the MIX Online family. One way to help draw the dotted line between future labs and MIX Online is consistent layout, and nothing shouts consistent like a decent implementation of a 12 or 16-column grid. Another thing we care about is that whoever is marking up the site is using consistent, clean and cross-browser friendly layout code. After all, we all roll up our sleeves on each other's work all the time. Frameworks like 960 and 1kb give us both and take the guesswork out of the layout process (possibly the most painful part of any web development exercise fondly known as Fire-the-designer-who-came-up-with-that-ridiculous-layout).
Having said all of this, I'm still not entirely sold (most likely because of the self-induced habitual superstition on the topic). I am, however, having tremendous difficulty coming up with reasons to hold off on dissolving my irrational fear of CSS grid frameworks. Would love to hear you argue either side (as you may point out something that'll save us some major heartbreak years from now). Leave a comment, or contact us on twitter.
Follow the Conversation
6 Comments so far. You should leave one, too.
You know my thoughts on this already, but for the sake of discussion… the problem I have with the use of these frameworks is not the lack of hand crafting, it is the names you end up having. On your site it isn’t terrible, but you have class=”row” on your main content area. Class is generally used only for presentation purposes, so I can understand why this doesn’t bother most people, but I prefer it if as much of the markup as possible (including the class attribute) is just describing the content and not the desired presentation.
Inheritance in CSS would solve my issue with this nicely… you could just say that #header inherits from the base class of row and your markup would be free of presentation issues, and all of that framework stuff like grid_4 would be contained inside your CSS file, leaving your 4 sections of information with names like who_am_i, instead of adding a “column grid_4” in there… that has nothing to do with the content and everything to do with the presentation.
Yes, I’m being picky, but one could say the same about people (like both you and I) who choose to make the header an [h1] instead of going with [div class=”bigHeader”] ... picky is good… opinionated development is good. Of course, getting done early is nice too, but I do wish we could use these grid frameworks by just mapping our existing semantic id and class names to their presentation focused ones.
In response to Duncan I guess one way you could get around this would be to have a dev tool plugin that would let you generate this code by applying the presentation classes and generating an ID based css markup.
Everyone has a sniping tool to check what styles are being applied and it wouldnt be a crime to have comments in your CSS to say #header follows row styling, #sidebar is a column grid_4 styling.
T4 Templates are getting a lot of hype recently – I wonder if this would be a good use for one?
Nishant. on the rainypixels site you have obfuscated your email in the visuals and left it clean in the markup – if that wasnt your intention you might want to change it :)
I think on the issue of using class tags its not such a big problem to use it for your own ends than misusing a H1 tag. The H1 tag only has one good use but from just taking a look at the html 4 spec to brush up the official definition of a class(http://www.w3.org/TR/html401/struct/global.html#h-7.5.2) it seems that it is intended “For general purpose processing by user agents.”
If you get a H1 tag wrong the its just plain wrong. If you put a wrong class in then you can still fix it by applying multiple classes which do make sense from the tag.
Before I dismissed it for the same reasons but I think I just changed my mind.
Dude I like the rainypixel background color, gives a nice warm feeling inside and very easy on the eyes.
How would a framework such as these integrate with JQuery?
If it helps to standardize the calls I’m making in laying out my pages and standardizes my JQuery calls… Then why not?
Thanx for this highlight!
This is the first time I’ve head about grid frameworks. I definitely should try one of these.
I started using grid frameworks for the first time today after watching a screen cast about 960. After looking into the available frameworks I chose blueprint. So far I’ve been pretty impressed by them. As long as you have solid grounding in css there is virtually no learning curve, and you can customise them as you like.
The only thing I will say about blueprint is that it is slightly ironic that you apply a class of “span-x” to a div. I wonder if they done that intentionally.