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.â€
Vote up?
22/12/2006
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!