The very talented Jeff Croft posts on CSS frameworks and the supposed myth of content and presentation separation, coming to the conclusion that it’s all a pipedream. I both agree and disagree.
Jeff says that never having to touch the markup, and only having to adjust the CSS for a redesign, is a myth. With this, I agree. If I’ve said it once, I’ve said it a million times: design is not decoration. So while I agree that most redesigns will involve changing markup, I disagree with the underlying premise that a redesign is a purely visual undertaking, and I disagree with the whole idea that one should never have to touch the markup. Which law is that? I would encourage anyone thinking that content/presentation separation or semantic markup (two completely different things) means that you’ll only need to change the CSS, to challenge this thought. They’re missing the point. This type of thinking reduces design to simply mean decoration. I didn’t study decoration for four years. My clients’ websites aren’t MySpace. We’re not skinning here. Since markup is structural, changing the structure of a design will certainly demand markup changes, and there’s nothing wrong with that.
Which brings me to CSS frameworks. Hmmm. Building a site so that you “only” need to change the CSS. This is pretty neat from a geek standpoint: can it be done? Is my framework better than your framework? But in reality, these CSS frameworks dictate to a certain extent how you’ll set up your structure. But shouldn’t the content dictate that?
Structure and meaning
The separation of structure/content and presentation is meant to manifest itself to the end user, not to the developer. When a site is stripped of all visual elements, the structured content of the site should still be accessible to the end user. There are two kinds of structure: document structure and visual structure. Document structure is the structure of the content itself. Visual structure is the physical structure of a page. We can distinguish these elements from each other through the use of semantic markup.
Semantic markup is all about meaning. When I say something is an “attention block”, I know what that means. Most importantly, fellow or future developers can figure out what an attention block is fairly quickly, even sans documentation. I can distinguish an attention block from an “urgent block” semantically, as opposed to only visually. But with all due respect to Jeff and others, what the hell is a span-4 or a pull-2? And how does this help future developers? Colleagues when I move to another company? Or portability, when the client wants a DocBook PDF of the entire site?
The new WYSIWYG
CSS frameworks are a nice idea, but they introduce the same problems the JavaScript frameworks or app/CMS frameworks introduce: they try to make things easier for the current developer, and in doing so make it terribly easy for less-experienced developers to create terribly scary, unruly HTML and CSS, while they don’t yet fully understand the basics. Sound familiar? Isn’t this the exact reason we hate WYSIWYG editors? Could CSS frameworks perhaps be the geek equivalent of WYSIWYG? With most frameworks, you must first get to know the framework if you want to work with it effectively. But we already know HTML and CSS. So what happens when client X asks me to do a redesign of site X, which uses CSS framework X? I either have to learn how framework X works and rework the site that way (focusing on implementing new elements using the framework, which will translate into costs for the client), or I’ll have to rebuild the whole thing. Rebuilding the whole thing is very tempting, because restrictions will be removed, and I can approach the site based on content, structure and visual design using the very basic tools of semantic HTML and CSS. The site will be portable and maintainable: anyone knowledgeable in HTML and CSS can maintain it; semantic markup is understandable markup. The site will be fairly future-proof, independent of framework version changes.
I’m not saying that frameworks are bad, but I challenge the reasons often given for using them. I consider them mainly beneficial to the initial developers. I also challenge any excuses designed to defend the discarding of semantic markup. I just don’t buy that span-4 and pull-2 are necessary. You have to use class names anyway, why not make them meaningful?
Use CSS frameworks if you will, but really consider your reasons for using them. Weigh the pros and cons. Not only for yourself, but for the site, the end users and your client, which also means future developers. Think about portability. Think about the fact that visual design is not simply decoration. Consider that visual design and document structure, although separated for portability/durability and the accessibility to the end user, are in fact inseparable.
As designer Paul Rand once said, “Design is a method of putting form and content together”. Our methods should involve embracing and strengthening this relationship, instead of working against it.
I’ll be speaking tomorrow in Utrecht, Netherlands on truths and myths regarding the Dutch Web Guidelines. I’d like to speak more about design in front-end development, but I guess the Web Guidelines are hot, and since I had a role in producing them, I get asked to talk about them. A lot.