The myth of the myth of content and presentation separation

There has been a lot of buzz recently about "CSS Frameworks." What's that you say? What is a "CSS Framework"? It's a fancy word for a base style sheet. But you see, the thing is that by calling something a "Framework," you can immediately pique the interest of any wannabe web developer.

There was a post over at JeffCroft.com regarding site redesigns and semantic markup which caught my attention today. Jeff brings up a few good points in his post:

• Most redesigns involve rewriting the HTML, so changing CSS class names is not a huge deal. (Agreed)
• Using non-semantic class names has no negative affect. (Agreed)
• Separation of content from presentation is a myth. (Whaaaa?)

Jeff then plugs a "CSS Framework" called Blueprint. (I'm going to continue to quote the term "CSS Framework" because it's a BS term used to manipulate people into thinking it's more than it actually is.)

The main gist of Jeff's post is that using semantic class names does not present any benefit over using non-semantic class names when it comes to most site redesigns because you are almost always going to revisit the (x)HTML during a site redesign. And since you will be revisiting (x)HTML, it is not going to add much overhead to change the CSS class names, so it's OK to use the non-semantic class names defined by a "CSS Framework" like Blueprint. Therefore, you should use a "CSS Framework."

Yes, it's true that using non-semantic class names doesn't hurt (it also doesn't add any benefit) and it may decrease development times (in very specific situations), but does it really mean that we should be using non-semantic class names (a la "Blueprint") instead of semantic ones? Jeff's argument is that by using a "CSS Framework," developers can create cross-browser layouts relatively easily. This is true, but anyone who actually knows CSS can do this without using pre-determined layouts & coding to a rigid framework. The reason why "Blueprint" was so useful for Jeff & LJWorld is because they needed to create lots of different layouts in very short timelines. So, for their situation, using a "CSS Framework" was a very smart solution. But for most web developers, this is not a realistic situation.

When you're developing a site from the ground-up, chances are that you have a few months to do it, and if you are working with a constantly-rotating team of developers, then using semantic class names is much more intuitive and descriptive than forcing everybody to learn the meanings of arbitrary class names defined by a "CSS Framework." It's much easier to see and understand the purpose of an HTML element labeled as "navigation" or "advertisment" as opposed to one labeled as "span-1" or "panel-4".

Let me point something out here: the reason CSS exists is to separate the presentation from the structure of an HTML document. By using a "CSS Framework" which utilizes class names that are purely presentational, you are re-introducing the very presentation-structure dependency which CSS was originally created to eliminate. Semantic class names, on the other hand, do not create this dependency. Imagine an HTML document (not a web page, just the HTML markup) with the following code:

versus something like...

If I am redesigning my site, and I'm using the "advertisment" class, all I need to do (theoretically) is to change the declarations made in my style sheet for that class name. But if I'm using a purely presentational "Framework" class name, then I must change my markup because I have created an artificial markup-presentation dependency. Since I'm using a pre-defined "Framework," I can't simply change the declarations in the css file for the "panel-4" class because I'll break every other element using that presentational class name. And chances are that these aren't going to be only "advertisement" elements. Even if I make a "compromise" and use a class name of "advertisment panel-4" there is still going to be a dependency on that non-semantic class name...

"But Jesse, if you are always going to be modifying the markup, then what is the big deal?"

Slow down there big fella! First you have to think about why you might be changing your markup. Why do most redesigns require re-working the actual HTML markup? Well, there are two big reasons:

1. The website is old or poorly written and doesn't have very logical or semantic markup.
2. The actual structure of the underlying document is changing.

Pay attention to that second point. The reason why most redesigns cannot be done using CSS alone is because the redesign is not purely cosmetic. Changing the grouping and organization of the page content is often a core reason for redesigning a web page in the first place. HTML is a very descriptive language, in the sense that HTML describes its content.

An HTML document should be able to stand on it s own. It should be completely understandable and make sense when it is viewed without stylesheets or javascript attached to it. Everything should "just work." Content titles should be enclosed in <hX> tags, etc.

HTML provides the structure to describe your content. And the structure of a document is almost always tied to its presentation. C'mon, what designer would display the navigation elements around the borders of a page or display the page header in the middle of a group of "current news" items? All navigation elements should be grouped together and therefore displayed in a common area and using a common style (generally speaking.) Who is going to argue with that? Thinking that you can isolate structure from presentation is a myth. Believing that you can separate presentation from content though, that's entirely possible.

While sites like CSS Zen Garden show the power of CSS, ultimately, having a well-structured web page to build a redesign off of is hardly ever the case in the real world. This is why redesigns almost always involve refactoring the (x)HTML markup of a web page. You can't build a house without a solid foundation. You can't win a world series without some solid pitchers. And you can't start a crazy religion like Scientology without mindless followers ;). For the time being, until markup becomes organized and reaches the level that it needs to reach, redesigns are always going to require more than simple CSS changes. Sites like CSS Zen Garden will still remain as an example of what can be done rather than what is being done - until websites begin to truly adopt web standards and smart markup.

Don't be a mindless sheep. Use web standards because of the great benefits you get from them. Don’t use web standards because Jeffrey Zeldman told you to. (link) Also, don’t think separation of content and presentation is a myth because Jeff Croft told you so. (link) Find the right tool for what you need to get done. But blindly listening to your friends (or the front page of digg) isn't always the best choice.