Why I changed my mind about the <main> element

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.

9 Responses to “ Why I changed my mind about the <main> element ”

Comment by Matt Wilcox

Interesting article, and good to (finally) learn why there’s that redundant property in the microdata spec. I rather hope it’s an optional property though, considering it’s uselessness for anything other than allowing “easier” learning.

As for main; I’m all for it if the accessibility argument is a good one and doesn’t cause issues.

Comment by Laura Kalbag

Thanks for helping us understand <main> better. It really helps to see both sides of the argument. And big respect to you for being willing to openly change your mind!

Comment by Terence Eden

Wonder how this will affect searching? I quite often get search results which include transiant features on a website (imported tweets, comments, adverts).

Theoretically, one could search for “Lawson sex tape in:main” to exclude all the sites tweeting about it etc.

Or, the reverse “terence eden insightful comment in:!main” to find sites where I’ve been particularly useful in the comments.

I suppose this also helps “reader” services and ad-blockers to identify which parts of the content can be stripped away.

Comment by Niels Matthijs

Great to read that this is being included in the spec (or at least it’s being proposed). I’m a big believer of direct targeting because that is exactly what we do when layering css and javascript on our html code. Being able to target a group of elements that belong together without any hassle (dl-dd-dt anyone) is a structural necessity of html, which is why my code is currently littered with ‘s (mostly targeted by parent > .main). Rejoice!

Comment by Alasdair King

Ah, the “content of interest” problem!

My WebbIE web browser does some heuristics on the rendered page to work out the likely start of the content of interest and crops pages to show only that text. I can chuck “has a main element” into the mix. That’s good.

Of course, only a few sites will use it, and many will misuse it. But still progress to see real useful semantic elements.

Comment by Scott Grodberg

I’d drop my vanilla content div for this in a heartbeat. Very interesting to see how a usability lab in an overlapping discipline inspired the change. Love that stuff; users rule!

Comment by John Foliot


With regard to your addendum, while “Test builds” may be doing the good mapping, most folks I know aren’t using test builds, they may in fact be using significantly older builds (even when browser vendors push their updates – sometimes those updates get blocked by “Corporate”, as I know only too well first hand).

For this reason there is no harm, and some potential benefit to be had, by doubling up <main role=”main”> for the immediate future. Small price to pay I would argue.