Laura Kalbag‘s recent blog post about the drawbacks of grid frameworks in web development has been getting a lot of attention the last few days. Although there are valid points in Kalbag’s post, I need to speak out about a few things that bothered me about the writeup.
Using a predefined grid makes as much sense as using a predefined colour scheme. —Jeremy Keith
The above quote is front and center of Laura’s post, and highlights my main issue with it.
Like grid systems, colour schemes are a necessity in any web design project.However, how you arrive at your colour scheme is totally irrelevant. You can create it by hand, or you might use something like Adobe Kuler to boost the process.
Same thing with grid systems. You can build a grid system from scratch, or you can download Bootstrap, Skeleton, 960.gs or something else – and build from there. I’m all for doing stuff from scratch, but if tools can help you shave a few hours off a tight schedule, why not use them? They’re not inherently bad.
The thing is, although all grid frameworks are ready-to-use, they’re not really something you should just download and casually drop into production code (unless you’re doing a quick prototype). Grid frameworks are tools – launchpads for your own grid systems.
Many grid frameworks even provide generators to help create custom grids (for example Gridpak or 960.gs). And if you implement your grid system correctly, you can even change your mind during development and swap to 12, 16 or 24 columns without breaking a sweat. This brings me to my next point:
I agree with Laura Kalbag about the bloated markup and bad semantics. Unfortunately, its hard to conceive the notion of a grid system without the common wrapper, row and column components. Kalbag likens grid systems to tables, but the argument is a bit poor. There’s a lot of reasons why HTML tables for layout are considered bad practice; shoddy markup is just one of them. And while grid systems and HTML tables share the same basic components (wrapper, rows and columns), grid systems are far more flexible in implementation. Be a little clever, and there’s very little extra markup needed – often just a few classes.
To illustrate: Its common practice to enclose a website or application in one or several wrapper containers (i.e. for horizontally centered layouts):
<body>
<div id="site" class="wrapper"><!-- Your site here --></div>
</body>
So, lets just use that for our grid wrapper.
The row is a bit more problematic. To keep things as semantic as possible, I try to apply the row where it makes sense, i.e.:
<header id="branding" class="row"></header> <nav id="access" class="row"></nav> <footer id="colophone" class="row"></footer>
Or even
<div class="products row">
<div class="product col"></div>
<div class="product col"></div>
</div>
In the final snippet, having a .products container probably serves a different purpose than just containing the columns. Try to create markup that works with the content and the grid system. Use semantic HTML5 tags where possible. It isn’t a sin to add a .row class to an <article> tag.
Finally, for the column elements (and this is the most important thing):
Applying the number of columns to span in the markup is a seriously bad practice. I’m talking about this awful thing:
<div class="featured-post span12"></div>
Instead, do this:
<div class="featured-post col"></div>
And then apply the number of columns to span in the stylesheet, i.e.:
.span12,
.featured-post.col {
width:100%;
margin:0;
}
Note: Its a good idea to have a generic column class (.col). The generic class can contain any attributes all the spans share (i.e. display:block; or the like), and it also makes it easy to keep track of which elements are actually included within the grid flow.
This approach might seem tedious compared to just dropping the .span12 class on the actual container. For some projects this might even be true, but here’s why you should do it anyway:
- Span classes in the markup is almost as bad as inline styling. You wouldn’t add width:100%; to the style attribute (or use a class like .full-width), would you?
- It makes it really easy to mix up the grid for responsive designs. Using media queries, you can easily vary the number of columns any individual element spans between breakpoints. You can even use different grid systems for different screen widths, if you’re really going to town.
- Obviously – changing the number of spans of a commonly used element no longer requires searching through loads of templates and markups and changing a bunch of classes. You just move the selector in the stylesheet. Done.
- Not happy with how the grid system performs? Throw it out and use another one. No need to edit the markup, just reapply the relevant span classes to the selectors.
Finally: I agree with Laura Kalbag in that its important to know your code. You shouldn’t find yourself in a position where you can’t recognize your own work a few months after completion. However, I feel this is a poor argument against frameworks (of any kind). Its usually more time consuming to build everything from scratch, than to just take the time to skim through the code of your third party parts and find out how stuff works, at least on the surface level. Doing this will make you far more equipped to implement things correctly, and to deal with bugs. You will also learn a lot by looking at other people’s code.
Today, being familiar with a vast selection of tools and timesaving shortcuts and knowing how and when to use them is a staple of a competent web developer. Many web developers are often stuck with tight deadlines or budgets on a seriously fragmented platform, saying you shouldn’t use a framework, library or tool because the end result is not 100% your work is, in my opinion, bad advice.
