Main element

There is an HTML5 extension specification that proposes adding a main element to HTML5.

• https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html

Summary: This page contains arguments for, rebuttals to arguments against, and research/data supporting the introduction of a main element to HTML/HTML5.

HTML5 has several new "block like" semantic elements (article, aside, section), including header and footer elements. There is no element to represent (and provide a hook for) for the "main content". The only landmark ARIA role that lacks an equivalent semantic HTML element is also called "main", and it is being used on real world websites.

This page contains:

• positive reasoning and supporting evidence for <main>
• arguments against <main>, with follow-ups
• counter-proposals to <main>, with explanation of inadequacies

Use cases

Though there are some documentation of use-cases elsewhere, it's helpful to provide some of these in this context to help with consideration of the proposal.

Reduce need for explicit skip links

One of the motivators was to get rid of skip links (http://webaim.org/techniques/skipnav/).

A main element would reduce work for authors.

Adding skip links is extra work for the author, particularly for accessibility, and thus it can be missed.

It would be less work for authors to simply use a main element. Authors naturally use the semantics of a main content area (with classes, id etc.) thus if they were given a main element to use, they'd easily use that instead (paving a cowpath).

Browsers could (user-configurably) provide some sort of built-in skip to main content gesture (link, or other mechanism).

Arguments for

In general there must be a high burden of justification for adding new elements, in order to keep the language easier and more usable overall. Every new element adds cost to learning/usability, and thus must more than make up for it in benefits.

paves a cowpath

A main element paves an already researched cowpath.

Or: it should have been included with header footer et al.

The introduction of <header>, <footer>, <aside>, <nav>, and <article> is based on careful consideration based on data gathered (in 2005).

Even according to Hixie’s research, the class “content” ranked higher than “nav” or “header”. It would be even more obvious if you took the sum of “content”, “main” and “body” (as class names or ids).

See https://developers.google.com/webmasters/state-of-the-web/2005/charts/top20-classes.svg .

That Hixie left <main> out in the first place is not justified by the research presented.

avoids last case of having to use an ARIA landmark

"Use of ARIA (a stop gap) should be a smell. Using it generally implies a weakness in native semantic, or, an abuse of native semantics." -David Bolter

Additionally, role=main is the most commonly used ARIA landmark per:

• http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-real-world-aria-landmark-use/

And it’s the only landmark that doesn’t have a one-to-one mapping to an HTML element name.

A main element would avoid the need to use role="main".

definitively answers a common question

On various development forums and sites, there are many questions of the nature: what HTML5 element do I use for the main content of my page? E.g.:

• Sitepoint: Main content area in HTML5 - what is correct ????
• Stack Overflow: HTML 5 element for content?

Given that web developers are already asking these questions (and getting wildly inconsistent answers), and that they're going to author *something* for what they consider the main content, a main element would naturally provide this functionality, and alleviate a common source of confusion.

Arguments against

Lack of concrete use case documentation

See previous Use cases section.

main does not meet a high bar of inclusion

Per the research cited in paves a cowpath, a main element meets a higher bar than "article" for example (which has plenty of real world use in blog posts), and certainly more than "hgroup" (which is debatable whether it should be kept or not).

Counter-proposals

Use existing markup instead

first article

Referred: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/037826.html

Summarized:

• To Authors: just use <article>. The main contents of a page are worthy of independently syndicating - nearly all content on the web works this way today.
• To Accessibility Tools: If you don't find a role=main element, then just use the first <article> in the page as if it were a <main> element.

The use of <article> instead also makes sense as a generalization of <main> that arises as soon as one thinks of how to write processing rules for the case where a page has more than one <main> even if it isn’t supposed to have more than one <main>.

Questions:

• Q: Where's the end of <main> content?
  • A: End of the last <article>.
• Q: How do you skip stuff between <main> elements?
  • A: Skip stuff between <article> elements.
• Q: Is it appropriate to use <article> in the gmail message list?
  • A: Yes, each message does have its own URL, and POP could arguably be a form of syndication.

problems with first article

Problems with the first article rule: [1][2]

1) The generalization no longer looks the way authors think. The cowpath being paved is hard to recognize. That is, the idea that you replace <div id=content> or <div id=main> with <main> is more intuitive than that you replace <div id=content> with <article> but you also replace each <div class=comment> with <article> and since the comments come after the main article, the first <article> ends up having the semantics of main content.

2) When role="main" exists, it’s hard to convince people that implicit works as well as explicit. Even if browsers actually exposed the right accessibility API role for first <article>, authors would still probably feel it’s better to say role="main" just in case. I would love to see ARIA obsoleted in the sense that people who don’t retrofit accessibility to legacy code and who aren’t recreating GUI widgets is JS wouldn’t need to deal with ARIA (where including role=main just in case because one doesn’t trust rules like “first <article>” counts as “needing” to deal with ARIA).

3) Even though in principle, the element names are just runes whose meaning is given by the spec—not by the English meaning of the element name, people still try to guess usage from the element name. It’s pretty easy to believe from element names alone than <main> is <div id=content> or <div id=main> made as a part of the language itself. It’s harder to grok the defined semantics of <article> from its element name.

4) It’s more obvious to write main { ... } in CSS than body > article:first-of-type { ... } (assuming the article is a child of body -- there's no way to write a selector for "first article in the document")

5) "first article" (and <main>) fails to handle a similar use cases:

   <section>
    <h1>Heading</h1>
    <aside> ... </aside>
    <nav> ... </nav>
    text...
    <aside> ... </aside>
    <aside> ... </aside>
    text...
   </section>

where you want to navigate from "Heading" to "text...".

Implementation impact

Notes on potential implementation impact of a main element on web browsers.

To be done right, <main> and <p> should interact the way e.g. <article> and <p> do.

Consider

• http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1939 and
• http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1940

vs.

• http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1942 and
• http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1941

Implementer feedback:

• Mozilla:
  • From a layout engine implementation point of view the burden is trivial.
  • The parser change would be absolutely trivial. There is absolutely no basis for opposing <main> on the grounds of amount of parser change work needed.

Implementation bugs

• Mozilla Firefox/Gecko: Bug 820508 Add support for <main> element
• WebKit: Bug 103172 - implement the HTML <main> element

Open issues

Different HTML parsing algorithms

It’s just unfortunate that if <main> was introduced, the HTML parsing algorithm wouldn’t be one exact thing but there’d be HTML parsing pre-<main> and HTML parsing post-<main> and during the transition, Web authors would have to explicitly write the

tag, which is supposed to be optional. However, we are headed to a world where there will be HTML parsing pre-<template> and HTML parsing post-<template> anyway.

Asides

Mesolithic analogy

It's interesting that debates over introducing a term for "the middle part" of something long predate this discussion, see for example the controversy over the introduction of the term "mesolithic":

http://en.wikipedia.org/wiki/Mesolithic#History_of_the_concept

as the thing between, Paleolithic (header), and Neolithic (footer). Despite the controversy, mesolithic is now an established term.