Last Updated on
Congratulations to The Mighty Steve Faulkner, whose proposal for an HTML5 <main> element was published yesterday by the W3C. I’m delighted to see one of the code examples features “The Lawson Academy”. Academy of what is left unknown.
@stommepoes asked me why I now support the introduction of <main> when previously I thought it unnecessary. So here’s why.
It’s always seemed to me to be a good plan to make elements out of common landmark patterns like navigation, footers, banners/ headers and the like. While the Scooby Doo algorithm mostly works to identify where main content begins, I was unsure that it always would, and most authors found the absence of a <main> element anomalous. Ease of authoring matters: the priority of constituencies in the HTML5 Design Principles says
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.
The Mighty Steve Faulkner is a very persuasive man – a kind of aussie Derren Brown of accessibility. He produced lots of data that suggested that people use <div id=”main”> (or similar names) properly.
Ian Hickson consistently claimed that such an element wasn’t necessary because the main content can be algorithmically determined so there’s no need to add extra cruft to the language – an argument which I’ve grown to consider “theoretical purity” and thus bottom of the heap in the priority of constituencies.
But, perhaps ironically, it was Ian Hickson who finally swayed me. When researching microdata and RDFa Lite, I noticed that a table comparing RDFa Lite and microdata said that microdata’s
itemscope attribute is “not needed” in RDFa. More pertinently, it’s not really needed in HTML5 microdata, either. As Matt Wilcox writes
itemscope is utterly pointless. The scope of the property is /always/ the scope of the tag to which it is applied. Making this extremely verbose and rather confusing.
The reason is there is that it makes it easier for authors. Hixie did user-testing of (seven) markup authors and wrote
I was really surprised by the itemscope/itemtype thing helping people, but it was a really stark result if I recall correctly. Originally I’d designed it with just one attribute “item”, whose value was optional but if present was the type. Confusion abounded in the usability lab when we tested that variant. We had a variant with the attributes split more or less like it is now, and the participants in the study were far more comfortable with that. One of the people who was tested on my original design saw the split variant near the end of their session, and it was like they had an epiphany.
It was quite an educational experience for me as a language designer. Things that I thought were obvious (URLs are too long and unwieldy to be used everywhere, terse markup is better than verbose redundant markup) were repeatedly shown to be false. It really changed how I design languages.
If it’s worth adding a redundant attribute to the language for something as comparatively esoteric as adding micro-semantics, it seems wrong to refuse to add an element that mirrors what vastly more authors actually write, and which would make the Web more accessible to those who need extra help.
And that’s why I support the addition of a <main> element to HTML5.
I’d be grateful if no-one told my wife or kids that I was wrong previously; they’re convinced I’m perfect.
Addendum 23 December: A few people have asked whether <main> would need an attribute
role=main too. I don’t believe so; according to Steve Faulkner, test builds of Firefox and WebKit already map <main> to the ARIA role, so no need to duplicate. Thus, if the assistive technology already supports ARIA role=main, it Just Works™ without the explicit role.