Thanks for the comments everybody. I’ve addressed them below:
@Seb:
I’ve heard the “divitis” charge before, but disagree strongly. The W3C says divs are “for adding structure to documents.” I take their guidance to heart: “this content is part of a column group” is correct usage. I’ve articulated that position on my blog and welcome discussion: http://nate.koechley.com/blog/2006/12/15/divitis_and_correct_div_usage/
+ Regarding class and ID names:
Names should not be based on appearance, but on meaning. For maximum extensibility, choose names that express semantic meaning (derived from the element’s content), and/or structural meaning (derived from the element’s role in the DOM’s tree). Good structural names include “footer” and “module”; good semantic names include “price” and “date”.
The common “doc” in doc, doc2, and doc3 is meaningful because this particular div is the document’s root node. It has no bond to a particular rendition or device. Similarily, “-b” (block), “-g” (grid), and “-u” (unit) classnames are meaningful yet neutral. The alternative, what-it-looks-like names such as “left” and “doc950px”, is contextually brittle (i.e., mobile) and temporally brittle (because things change). These are the same reasons professional consensus says class=“redButton” and class=“smallBoldVerdana” are undesirable.
+ Regarding the hacks for IE (*property) and IE7 (_property):
You’re right, you could pull those out into version-specific sheets exposed by conditional comments. I’ve included them in a single file in this case for two reasons. First, additional HTTP requests hurt performance. I value performance before validity, especially for infrastructure.
Second, the main argument against including CSS hacks — that they’re hard to manage — is moot in this case. CSS hacks are tedious, risky, and expensive to manage, and for those reasons I discourage intermingeling them in large codebases. But in this case the file is of encapsulated scope, is centralized, and has dedicated and permanent maintenance staff.
+ Does it work for demanding designs?
While everything’s breakable, the short answer is yes. It’s been used successfully on glossy sites with all the Web 2.0 trimmings: drop shadows, nested borders, rounded-corners, gradients… YUI Grids is a dependable skeleton. If you need more hooks, it’s rugged enough that you can embed your own markup and it won’t break.
@Karl:
Great to hear you were able to port your redesign so quickly! Very happy to hear it.
@Tony:
I definitely hear you when you say “you don’t know any HTML designer who wouldn’t take pride in creating” their own, It’s true, us geeks are a proud lot. But for my money, I don’t know many without something more interesting to do than reinvent the wheel. Efficient tools let us reach farther, but are never required.
+ What about those not interested in handcoding?
Dav Glass has created an outstanding wizard for building YUI Grids: http://blog.davglass.com/files/yui/grids/
Of course, your general argument applies to any tool, in any context, from “Ruby on Rails makes programming too easy!” to “painting with premixed colors is boring.”
Nate Koechley
Thanks for the comments everybody. I’ve addressed them below:
@Seb:
I’ve heard the “divitis” charge before, but disagree strongly. The W3C says divs are “for adding structure to documents.” I take their guidance to heart: “this content is part of a column group” is correct usage. I’ve articulated that position on my blog and welcome discussion: http://nate.koechley.com/blog/2006/12/15/divitis_and_correct_div_usage/
+ Regarding class and ID names:
Names should not be based on appearance, but on meaning. For maximum extensibility, choose names that express semantic meaning (derived from the element’s content), and/or structural meaning (derived from the element’s role in the DOM’s tree). Good structural names include “footer” and “module”; good semantic names include “price” and “date”.
The common “doc” in doc, doc2, and doc3 is meaningful because this particular div is the document’s root node. It has no bond to a particular rendition or device. Similarily, “-b” (block), “-g” (grid), and “-u” (unit) classnames are meaningful yet neutral. The alternative, what-it-looks-like names such as “left” and “doc950px”, is contextually brittle (i.e., mobile) and temporally brittle (because things change). These are the same reasons professional consensus says class=“redButton” and class=“smallBoldVerdana” are undesirable.
+ Regarding the hacks for IE (*property) and IE7 (_property):
You’re right, you could pull those out into version-specific sheets exposed by conditional comments. I’ve included them in a single file in this case for two reasons. First, additional HTTP requests hurt performance. I value performance before validity, especially for infrastructure.
Second, the main argument against including CSS hacks — that they’re hard to manage — is moot in this case. CSS hacks are tedious, risky, and expensive to manage, and for those reasons I discourage intermingeling them in large codebases. But in this case the file is of encapsulated scope, is centralized, and has dedicated and permanent maintenance staff.
+ Does it work for demanding designs?
While everything’s breakable, the short answer is yes. It’s been used successfully on glossy sites with all the Web 2.0 trimmings: drop shadows, nested borders, rounded-corners, gradients… YUI Grids is a dependable skeleton. If you need more hooks, it’s rugged enough that you can embed your own markup and it won’t break.
@Karl:
Great to hear you were able to port your redesign so quickly! Very happy to hear it.
@Tony:
I definitely hear you when you say “you don’t know any HTML designer who wouldn’t take pride in creating” their own, It’s true, us geeks are a proud lot. But for my money, I don’t know many without something more interesting to do than reinvent the wheel. Efficient tools let us reach farther, but are never required.
+ What about those not interested in handcoding?
Dav Glass has created an outstanding wizard for building YUI Grids: http://blog.davglass.com/files/yui/grids/
Of course, your general argument applies to any tool, in any context, from “Ruby on Rails makes programming too easy!” to “painting with premixed colors is boring.”
@Michael: Thanks!