Evert wrote:
I am still having problems accepting the differences between <section> and <article> though. I understand when to use one over the other, but what was the background for choosing two elements instead of one? What is the drawback of defining just one in the spec (either <section> or <article>) and giving that one all the use cases and abilities of the two? I don't see how that would affect anything (not even AT).
An excellent question. And I think it's very telling that this overlap is confusing for a working web developer looking at the spec with a fresh perspective.
<section> and <article> used to be somewhat different. <article> used to take optional @cite and @pubdate attributes.
Now <section> and <article> are pretty much identical (the only content model difference being that <article> may contain a <time> element with an optional @pubdate attribute). The only semantic difference between the two elements is an adjective: "standalone" (or "independent"), which applies to <article> but not to <section> ...even though <section>, by definition, is a collection of related content.
The only justification I've heard for the continued existence of two new elements when just one will do, is that it will help authors of blogs from adding class="post" to their entries. That is an extremely flimsy justification, one that could be used to justify adding hundreds of new elements to HTML5 (e.g. <recipe>, <comment>, <story>, <widget>).
I'm most puzzled by the cognitive dissonance between the refusal to drop a redundant new element like <article>, and the refusal at all costs to add new elements where they would be genuinely useful (such as a labelling element for <figure> and <details>).
-- Jeremy Keith a d a c t i o http://adactio.com/
