A Day Apart in Seattle was more like a seminar than a workshop. Rather than being an intimate gathering in a small room, it was more lecture-like in an amphitheatre setting. But that didn’t stop me interacting with the attendees. There were plenty of great questions throughout, and I also had everyone complete an exercise.
I reprised the exercise I gave at dConstruct back in September. It isn’t a test of the audience. Rather, it’s a test of how well the new structural elements in HTML5 are described:
I then asked the attendees to match up the definitions with the element whose name sounded like the best match. To be clear: this wasn’t a test of knowledge. I was testing the spec.
The results from September’s test were quite revealing. There was some confusion between footer
and details
. Since then, the definitions in the spec have been updated and I’m happy to report that the Seattle audience—a much larger sampling—were almost unanimous in correctly matching element names to their definitions.
With one glaring exception.
The section
and article
elements were, once again, confused. This happened back in September at dConstruct. It happened again at A Day Apart in Seattle. I didn’t get exact numbers, but from the very web-savvy audience of about two hundred people, I would say there was a 50/50 split in matching up the definitions of section
and article
. About 50% of the attendees thought that the definition of section
applied to article
and visa-versa.
Historically, article
and section
were more distinct. The article
element used to have optional cite
and pubdate
attributes. Now their content models are identical (apart from the fact that the article
element can take an optional time
element with a pubdate
attribute).
The only thing that distinguishes the definition of article
from the definition of section
is the presence of the phrase self-contained
. A section
groups together thematically-related content. An article
groups together self-contained thematically-related content. That distinction is too fine to warrant a separate element, in my opinion.
The existence of two elements that are practically semantically identical isn’t a harmless addition to HTML5. It’s causing a great deal of confusion. I’ve spoken to authors who incorrectly assumed that articles had to be within sections or that sections could only be within articles. The truth is that you can have sections within articles, articles within sections, sections within sections, articles within articles, or any other combination you can think of.
This isn’t helpful. Authors are confused. Yet, according to the HTML Design Principle of Priority of Constituencies:
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.
I don’t understand why Hixie is still clinging to the addition of the article
element when he has repeatedly stated that he wants to keep the number of new elements to a minimum. Here’s the perfect opportunity: merge section
and article
into one element. Personally, I would keep section
, with its more generic-sounding name.
We’ve been here before. The abbr
and acronym
elements were responsible for years of confusion amongst authors unsure of which one to use. The use-cases and the definitions of both elements were just too similar. That particular problem has been solved in HTML5: the acronym
element is now obsolete. The abbr
element works well enough for both use cases.
Let’s not repeat the mistake of abbr
and acronym
with article
and section
.