One of the hallmark attributes of web standards-based design is the concept that proper use of semantic (X)HTML and CSS completely abstracts the presentation of a site from its content. One key real-world benefit of this separation is that come redesign time, one only needs to change or replace the CSS stylesheet, and needn’t lay so much as a finger upon the hallowed grounds we call markup. I’m here to say that this mantra isn’t much more than a fairy tale.
Don’t get me wrong. It is absolutely a best practice to separate your content, presentation, and behavior layers as much as possible. No doubt, doing so does make for easier maintenance — and brings several other benefits, as well. It’s a noble goal to strive for, and I think we all should do so. But the idea that a redesign of anything more than the most basic of sites will not require changes to (X)HTML markup is simply a myth. I’ve been in this web standards game for five years now and probably have over 100 standards-based sites under my belt. I can count the number of times I’ve be involved in a redesign where no changes were made to the markup on one finger. And that time, I wanted to change the markup, but couldn’t for reasons out of my control.
I bring this up in response to some criticism of Blueprint, a publicly-available CSS framework which borrows heavily from a CSS grid component Christian Metts, Nathan Borror, and I built at The Lawrence Journal-World. Although Blueprint has largely received very positive feedback from the web design community, some people are bothered by the non-semantic (and semi-visual) class names, some examples of which are
The concern is valid — Nathan, Christian, and myself were all bothered by it, too. But after some thought and playing with the framework, we realized a few things:
- Non-semantic class name hurt nothing.
- The productivity and efficiency boost we got by all designers using a consistent framework that already accommodated for browser issues was enormous.
- We were never, ever going to redesign our sites without changing the (X)HTML. It’s a nice thought, but it’s also a total pipe dream.
So, if we’re always going to revisit the (X)HTML at redesign time, use of visual class names doesn’t negatively impact our work, and we can create good, solid layouts in very little time — what’s not to love about (the framework that became) Blueprint?
If there’s one thing I wish I could use my position in the industry to convey to others, it’s this: Use Web Standards because of the great benefits you get from them. Don’t use Web Standards because Jeffrey Zeldman told you to. Where Web Standards and other best practices don’t provide great benefits, find solutions that do.
Oh, and check out Blueprint. It’s awesome. :)
Update: I posted another entry to more clearly define what I meant by the “Don’t use Web Standards because Jeffrey Zeldman told you to…” line.