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.
For the record, I don’t think we disagree at all. I agree completely that the content, not the visual presention should dictate the structure and markup. I agree that using a framework like Blueprint, you eschew that principal in favor of simplicity and speed.
However, I also know that there are real-world situations where time and resources are strained and the productivity boost this type of framework can provide is sometimes more valuable than 100% pure semantic goodness.
When I work at the Journal-World, it was common for me to be expected to create complex grid-based layouts for a story or special section in a matter of an hour or two. These needed to work in many browsers, including IE6 and lower. It was simply unpractical for me to build these from scratch every time — I just didn’t have the time for it. By coming up with a set of classes that could be reused, I was able to achieve this kind of speed.
So, we agree. span-4 and pull-3 aren’t ideal classnames. But, in some situations, they’re good enough, especially when they provide a massive increase in productivity.
Jeff, I agree that we agree. ;-) Believe me, we also deal with hairy deadlines. My point is that what takes less time now, might cost more (time) in the future. I prefer to avoid this type of situation. Of course, in situations like yours, I understand and respect your approach.
I do think that frameworks like Blueprint, because they are so versatile and useful, will be used outside of the one- or two-hour deadline realm. If you agree with me that semantic markup has practical applications (as opposed to semantic markup for it’s own sake), then you might agree with me that it would be worth investigating the possibility of taking a framework like Blueprint and polishing it to include these best practices we’ve all been preaching for the past few years.
Unfortantley, I think a CSS framework like Blueprint and 100% semantic markup are mutually exclusive. I don’t think it would be possible to achieve both. The very point of Blueprint is to establish some classes that can be reused from site-to-site. As you said, structure should be defined by content. Since the content of every site is different, the only way to get the strucure 100% correct if to create those class names specifically for every site.
Might be interesting to try, though ;-). At Cinnamon, we’ve been discussing the pros and cons of CSS frameworks vs. well-organized, flexible and reusable CSS libraries. There’s no doubt that Blueprint has ignited a fascinating discussion. Thanks for your feedback, Jeff.