At the dawn of the standards revolution came the phenomenon of DIV-itis.
It was well-meaning but naïve developers, for whom converting from tables for layout simply meant exchanging every <table> and <td> tag for a corresponding <div>.
Many people even spoke of converting my site from tables to divs
, as though that were the only point of it; all the while completely missing the real purpose, of converting from visual to semantic markup.
Then came the lists — lists upon lists upon lists — and with it a new, yet closely-related pandemic, the latter phenomenon of LIST-itis. What started with an inspired idea for adding meaning to navigation lists, became, to some, the miracle cure-all of pseudo-semantic markup, as every possible structure was ratified into lists. Honestly, people built whole sites with almost nothing else!
A Little Bit of History Repeating
And now it’s happening again!
I like to poke around the source-code of interesting sites (always been a bit of a markup-trainspotter that way). But recently I’ve been seeing tremendous over-use of the <section> element, like this real-world example (where I’ve removed the various attributes and inline-markup for simplicity):
<body>
<section>
<section>
...
</section>
</section>
<header>
<section>
...
</section>
</header>
<section>
<section>
<section>
<section>
...
</section>
</section>
</section>
</section>But the section element is not a container, and shouldn’t be used to wrap around arbitrary chunks of content, for styling or layout purposes.
To quote the draft specification:
The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead. A general rule is that the section element is appropriate only if the element’s contents would be listed explicitly in the document’s outline.
So most of those <section> elements should probably be <div> instead.
Escaping From The Past
I don’t blame anyone for confusion. The draft specification itself is vague or contradictory in many places; it is a draft, after all.
For example, it’s still far from clear what the <article> element is really for. Does it wrap around sections that link to articles? Does it wrap around the content of the article? Does it wrap around the whole page that contains the article? Or is it just for syndication? Exactly what is an article
anyway? (And why isn’t there a <content> element?)
Eventually, the spec will have to clarify all its ambiguities; either that, or we’ll end up settling on a bunch of generally-accepted but non-ratified conventions as to what things mean (which would be unfortunate, especially since that’s exactly the kind of thing HTML5 is trying to avoid).
In the meantime, I fear we’ll see more and more enthusiastic-but-premature experiments with HTML5, mistreating its elements to impart confusing or contradictory semantics, or as physical layout blocks for things that are clearly the job of a <div>.
There seems to be something of a ‘too cool for school’ attitude around the use of <div> in HTML5, like they’re seen as out-dated, unfashionable, crude, or that they shouldn’t be necessary anymore. It’s certainly true that we’ll no longer need them for things that now have specific, semantic elements, such as <header> and <footer>; but for a long time yet, we’re still going to need them as neutral, structural containers. Such containers are critically necessary in web-page and interface construction, still compensating as they do for the near-terminal inability of CSS to define workable, structural layout properties for blocks and pseudo-blocks!
Designing For The Future
I could argue that, in the absence of clearly-defined meaning for the semantics of a new element, it shouldn’t be used at all. Because who are the semantics really for? They’re for access-technologies (like screenreaders), search-engine spiders and other kinds of robot. Yet how can these machine-readers derive interoperable meaning from element semantics, when even the author of those semantics isn’t really sure what they mean?
Oh well. I’m not expecting to change anybody’s mind on this.
So for those of you keen to press ahead with trail-blazing this standard-to-be, I’d simply ask you to remember — not to treat as visual or structural markup, what is really semantic markup.
And beware of SECTION-itis!
James EdwardsJames is a freelance web developer based in the UK, specialising in JavaScript application development and building accessible websites. With more than a decade's professional experience, he is a published author, a frequent blogger and speaker, and an outspoken advocate of standards-based development.
