Jeff Croft's Myth of Content/Presentation Separation
August 18, 2007
Jeff Croft wrote an excellent piece entitled The myth of content and presentation separation on criticism of the new Blueprint CSS Framework. I’ve been a big standards-proponent since 2000—at the time the few designers involved in the movement were revolting against the divergence of IE and NS and the incredible wastefulness of the tag-soup style of HTML that was prevalent at the time. Conventional wisdom was that tools abstracted away most of the nastiness and technology like CSS was too immature to be useful. Embracing standards at the time meant sacrificing a lot of control in order to work towards a solution to much deeper fundamental problems.
The standards movement was founded out of pragmatism at a time when marketing dollars obscured the cancerous state of the web. That’s why I find it so ironic now to see a full-fledged cult based on the notion of semantic markup. Legions of followers of this philosophy that obsess over every tag and class name, and instantly deride anyone’s work who doesn’t live up their particular obsession. It’s like they never saw the wasteland of verbose and redundant tag soup that inspired guys like Zeldman to think “there must be a better way.”
The fundamental flaw is believing that content and presentation can be totally separate to begin with. It’s one thing to avoid smashing them together into a coarse paste as the original standards movement sought to remedy. But at the same time, realize that the primary use of HTML is to add structure to a document for purposes of presentation. Sure, some semantic information can be extracted by search engines and other data aggregators, but that primarily extends to HTML tags and to a lesser extent standardized microformats. A lot of the criticism of Blueprint centers around class names, which offer very little aggregate benefit since they are not standardized. Sensible class names make your CSS easier to read, but that’s a human benefit; the names should convey the most important information that future maintainers will need to know.
Even if you believe that every tag and attribute can and should have a non-presentational meaning, you still can’t markup everything. You can’t describe the meaning of every block, image and sentence in a meaningful way. If you tried, the result would require malformed overlapping tags. So the tags you choose (and the ones present in HTML) are deemed the ones of the most value, and presentation is very often the highest value.
Sometimes you have to stick a tag or class in just as a hook for your CSS. In these cases it makes sense to pick a meaningful name. Sometimes the most meaningful name is presentational. A great example is <div class="sidebar">. A sidebar is common construct both print and web layout. A “semantics” cultist might argue that it should be named according to what actual information it contains. But that is ludicrous. The whole point of the tag is for layout. Every page might contain different contents, and you certainly don’t want 50 CSS classes that all do the same thing. Instead of polluting your semantic markup with presentational information, you’re filling your presentation layer with unnecessary repitition. It’s no less insidious than a thousand <font color="red"> tags.
The painful (to some people) truth is that there is an irreducible tension between content and presentation (and behavior). What we are going for with CSS is known as “loose-coupling” in programmer speak, but it seems some people have this ideal in their head of “no-coupling”, which of course is impossible.
Aside from the many great comments in the discussion at Jeff’s blog, one particular quote from the article rings true for me:
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 been involved in a redesign where no changes were made to the markup on one finger.
Inevitably several people chimed in with counter-examples. It’s true that well-written HTML and an increasing list of CSS features and browser support allow the range of pure CSS redesign possibilities to constantly expand. The redesign possibilities with pure CSS changes are literally infinitely more than they were 10 years ago. And with complete browser support the creative power of CSS could be increased by an order of magnitude.
But even so, if your content isn’t in the right blocks, or you don’t have all the hooks you need, markup is going to require changes. HTML just isn’t rich enough of a format to begin with. If you wanted true semantics you would get much closer with XML+XSLT to transform your raw data in a presentable form. And even XML is a pretty weak semantic model compared to what you can do with relational databases.
Personally I find a lot of value in the simple balance of semantics, presentation, and behavior that HTML + CSS + Javascript provide, but I find it shocking how some people take it to the extreme of total semantic purity. Presentational semantics are not an oxymoron—in fact they are a critical part of the web.
Jeff Croft's Myth of Content/Presentation Separation
Jeff Croft wrote an excellent piece entitled The myth of content and presentation separation on criticism of the new Blueprint CSS Framework. I’ve been a big standards-proponent since 2000—at the time the few designers involved in the movement were revolting against the divergence of IE and NS and the incredible wastefulness of the tag-soup style of HTML that was prevalent at the time. Conventional wisdom was that tools abstracted away most of the nastiness and technology like CSS was too immature to be useful. Embracing standards at the time meant sacrificing a lot of control in order to work towards a solution to much deeper fundamental problems.
The standards movement was founded out of pragmatism at a time when marketing dollars obscured the cancerous state of the web. That’s why I find it so ironic now to see a full-fledged cult based on the notion of semantic markup. Legions of followers of this philosophy that obsess over every tag and class name, and instantly deride anyone’s work who doesn’t live up their particular obsession. It’s like they never saw the wasteland of verbose and redundant tag soup that inspired guys like Zeldman to think “there must be a better way.”
The fundamental flaw is believing that content and presentation can be totally separate to begin with. It’s one thing to avoid smashing them together into a coarse paste as the original standards movement sought to remedy. But at the same time, realize that the primary use of HTML is to add structure to a document for purposes of presentation. Sure, some semantic information can be extracted by search engines and other data aggregators, but that primarily extends to HTML tags and to a lesser extent standardized microformats. A lot of the criticism of Blueprint centers around class names, which offer very little aggregate benefit since they are not standardized. Sensible class names make your CSS easier to read, but that’s a human benefit; the names should convey the most important information that future maintainers will need to know.
Even if you believe that every tag and attribute can and should have a non-presentational meaning, you still can’t markup everything. You can’t describe the meaning of every block, image and sentence in a meaningful way. If you tried, the result would require malformed overlapping tags. So the tags you choose (and the ones present in HTML) are deemed the ones of the most value, and presentation is very often the highest value.
Sometimes you have to stick a tag or class in just as a hook for your CSS. In these cases it makes sense to pick a meaningful name. Sometimes the most meaningful name is presentational. A great example is
<div class="sidebar">
. A sidebar is common construct both print and web layout. A “semantics” cultist might argue that it should be named according to what actual information it contains. But that is ludicrous. The whole point of the tag is for layout. Every page might contain different contents, and you certainly don’t want 50 CSS classes that all do the same thing. Instead of polluting your semantic markup with presentational information, you’re filling your presentation layer with unnecessary repitition. It’s no less insidious than a thousand<font color="red">
tags.The painful (to some people) truth is that there is an irreducible tension between content and presentation (and behavior). What we are going for with CSS is known as “loose-coupling” in programmer speak, but it seems some people have this ideal in their head of “no-coupling”, which of course is impossible.
Aside from the many great comments in the discussion at Jeff’s blog, one particular quote from the article rings true for me:
Inevitably several people chimed in with counter-examples. It’s true that well-written HTML and an increasing list of CSS features and browser support allow the range of pure CSS redesign possibilities to constantly expand. The redesign possibilities with pure CSS changes are literally infinitely more than they were 10 years ago. And with complete browser support the creative power of CSS could be increased by an order of magnitude.
But even so, if your content isn’t in the right blocks, or you don’t have all the hooks you need, markup is going to require changes. HTML just isn’t rich enough of a format to begin with. If you wanted true semantics you would get much closer with XML+XSLT to transform your raw data in a presentable form. And even XML is a pretty weak semantic model compared to what you can do with relational databases.
Personally I find a lot of value in the simple balance of semantics, presentation, and behavior that HTML + CSS + Javascript provide, but I find it shocking how some people take it to the extreme of total semantic purity. Presentational semantics are not an oxymoron—in fact they are a critical part of the web.