Saturday, October 24, 2009

The difference between Table-less and Semantic Markup

As organizer of a Web Design Meetup, I get to hear all manner of conversation about Table-less Web design from both expert and amateur designers. But their focus is inevitably about what it is someone else has told them about the evils of the <table> tag, and separation of something they call "style" from something they call "content". Before any of the current crop of born-again post-Flash designers came around, we structured markup types focused upon separation of structure and semantics... distinguishing between the syntactic forms and the meanings or behaviors applied. The ill-defined terms "style" and "content", though present in the markup world prior to the Web, have come to be accepted HTMLisms with apparently much narrower meaning.

People think, for instance, that the following snippet (taken from a CSS Zen Garden theme) is wonderful, because it separates something (style) from something else (content):

<div id="container">
<div id="intro">
<div id="pageHeader">
<h1><span>css Zen Garden</span></h1>
<h2><span>The Beauty of <acronym title="Cascading Style Sheets">CSS</acronym> Design</span></h2>
</div>

<div id="quickSummary">
<p class="p1"><span>A demonstration of what can be accomplished visually through <acronym title="Cascading Style Sheets">CSS</acronym>-based design. Select any style sheet from the list to load it into this page.</span></p>
<p class="p2"><span>Download the sample <a href="/zengarden-sample.html" title="This page's source HTML code, not to be modified.">html file</a> and <a href="/zengarden-sample.css" title="This page's sample CSS, the file you may modify.">css file</a></span></p>
</div>

<div id="preamble">
<h3><span>The Road to Enlightenment</span></h3>
<p class="p1"><span>Littering a dark and dreary road lay the past relics of browser-specific tags, incompatible <acronym title="Document Object Model">DOM</acronym>s, and broken <acronym title="Cascading Style Sheets">CSS</acronym> support.</span></p>
<p class="p2"><span>Today, we must clear the mind of past practices. Web enlightenment has been achieved thanks to the tireless efforts of folk like the <acronym title="World Wide Web Consortium">W3C</acronym>, <acronym title="Web Standards Project">WaSP</acronym> and the major browser creators.</span></p>

<p class="p3"><span>The css Zen Garden invites you to relax and meditate on the important lessons of the masters. Begin to see with clarity. Learn to use the (yet to be) time-honored techniques in new and invigorating fashion. Become one with the web.</span></p>
</div>
</div>


And the code goes on. Now, I don't have a problem with it as far as it goes. They've done two things here:
1. Separated the CSS syntax from the HTML markup
2. Used most of the HTML markup element types names in the manner more-or-less specified in the W3C Recommendations

But look again at the markup. Oodles of nesting. DIV DIV DIV P and DIV DIV DIV H SPAN ... gosh that looks a helluva lot like tables, just with different element names. Oh, I know, I know, table semantics vary between implementations, and implementations are broken, and there are lots of good reasons for not using tables that don't directly affect other nestings of elements. And both DIV and SPAN are "semantic free" (sort of: DIV has the semantics of a generic block-level element, and SPAN has the semantic of a generic in-line level element). But you are still relying upon the side-effects of the style semantics implied by the nesting of the markup to achieve a style effect. Six of one, three of another, I agree the balance is in favor of DIV. But you've still got markup code that exists just for the sake of style. And that is not cool, not even Zen like.

When you're talking about separation of concerns, the style is all over the code like marinara sauce on spaghetti. The markup, by the way, says that the HTML page has seventeen major content divisions, all well and good because DIV just means a grouping of elements that is (usually) formatted as a block. But I object that "UL" is only barely related to the semantic of "menu", and other pages on the site use a sequence of "P" elements to represent the same menu. Please don't tell me this stuff separates the style semantics from the informational content -- clearly it really only separates CSS coding from HTML coding.

I understand it can be hard for Web designers, even the most experienced, to grok abstract concepts such as syntax, semantics, semiotics, and pragmatics. You've got pages to pump out, and such subjects may amount to mere philosophical diversions to when your concern is primarily producing digital marketing collateral and not performing professional information management. But understand that if something is worth doing well, it is a valuable exercise to understand what happens when go all the way, or at least push the boundaries.

On my soapbox, not only is the meme of "separate style and content" not fully realized in Table-less HTML coding, popular practice reaches precisely the opposite effect. The semantics of style are hard-coded into almost all of the HTML markup tags themselves. People just pick on TABLE because it is a scapegoat: the whole tag set is guilty. Never mind about Web 2.0: the Web has been stuck in beta mode for the past twenty years with a set of page style primitives that were accepted because they were free, not because they were good or even "good enough". HTML is wild and woolly, full of fun and frolic, but one thing it is not is a clean design. And that's my hot-button, because all this talk of separation of style and content in HTML is like dressing a pig in Prada.

Off my soapbox, I observe that the semantics of style include layout functions, what printers call imposition, and what in my experience involves staging functions for information content, not just colors, margins, backgrounds and borders. That's precisely where the Table-less discussion falls apart, because it doesn't go far enough. The bottom line is that "Table-less" is not enough. To separate style from content means so much more.
Post a Comment