Jump to content
Thanks for the comments everybody. Iâ€™ve addressed them below:
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.
Great to hear you were able to port your redesign so quickly! Very happy to hear it.
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.â€