Main element joins HTML draft-- webmonkey

This has actually been going on for several months now, but I still wanted to share this webmonkey article about the <main> element

For those wondering why a <main> element:

While HTML5 brought in new elements to mark up everything else on the page, there was nothing that clearly said (to AT, scrapers, and plugins like Readability, whose job it is to pull out the actual real content of a page and ignore all the other cruft) that “this is the point of this page”. Instead, software was expected to use what Bruce Lawson dubbed “the Scooby-Doo algorithm”: after seeing everything else on the page marked up as something else, like <nav> or <header> or <footer> or <aside>, the main content must be whatever’s left over. This “algorithm” would fail easily on pages where

  • authors didn’t bother actually using all the other elements correctly; with <main>, they only need to get one tag right.
  • where the “main” area is still mixed up with many <article>s with <header>s and whatnot, and <aside>s mixed in. Since a Scooby-Doo style algorithm would try to exclude those, no main content would be found. With a <main> element, you can now explicitly say “these articles and structural stuff inside are all considered the main content of this page”.

There was enough evidence that authors (we) would use main correctly, even more correctly than other elements (that is, authors are still using multiple <nav> elements per page, using <menu> for navigation, overnesting <section> and <article> because of a feeling that “divs 'r bad, mmkay?”) by looking at the class and id names generally given to divs containing what the author considered the main content.

Main does not affect the so-called “document outline” like <section> and <article> do. It merely lets software (and users of that software) know where on the page the content is that the authors consider the Whole Point. Ideally plugins and software like Readability would work even better with <main> elements. Of course <main> also has a landmark role, “main” for easier navigation by some AT users. The role existed first and the <main> element would now be mapped to it by default.

Unfortunately it’s a darn shame that you need to be using AT to navigate by landmark roles, arg.

An example.


<!doctype html>
<head>
  <meta charset="utf-8">
  <title>Foos and Bars</title>
  <meta name="description" content="How Foos and Bars enhance our lives in a spiritual way.">
  <link rel="stylesheet" href="css.css">
</head>
<body>
  <header role="banner"> (very redundant in this case, pretend there's craploads of stuff in the header)
    <p><a href="/"><img src="foobarco.png" width="80" height="80" alt="The Foo and Bar Company"></a></p>
  </header>
  <nav role="navigation">
    <ul>
        <li><a href="">blah</a></li>
        <li><a href="">blah</a></li>
        <li><a href="">blah</a></li>
        <li><a href="">blah</a></li>
        <li><a href="#products">To the product menu...</a></li>
    </ul>
  </nav>
  <main role="main">
    <section>
      <header> (more redundancy but people like fancy new tags)
        <h1>Foos and Bars: a case study</h1>
      </header>
      <p>blah blah...</p>
      <section>
        <header>
          <h2>Foos</h2>
        </header>
        <footer>
          <p>Written for FooBarCo by Elmo in 1996</p>
        </footer>          
        <p>blah blah...</p>
      </section>
      <section>
        <header>
          <h2>Bars</h2>
        </header>
        <p>blah blah...</p>
        <section>
          <header>
            <h3>Bar-Quuxes: a maze of twisty little passages</h3>
          </header>
          <p>more blah...</p>
        </section>
      </section>    
    </section>  
  </main>
  <aside role="complementary">
    <h2>Archive of FooBarCo articles</h2>
    <h3>Feb</h3>
    <ul>
      <li><a href="">blah</a></li>
      <li><a href="">blah</a></li>
       ...
    </ul>
    <h3>Jan</h3>
    <ul>
      <li><a href="">blah</a></li>
      <li><a href="">blah</a></li>
      ...
    </ul>
  </aside>
  <footer role="contentinfo">
    <p>Stuff about contact info, address, copyright, blah blah...</p>
  </footer>
</body>
</html>

Honestly the reason I don’t use section or article is because they’re almost always not needed, but if you’ve got lots of “boxing” divs grouping content then those would be it. There were questions like "why not just have <article role=“main”>? There’s still discussion of this, but <article> is a sectioning element (affects the document outline) while <main> is not, leaving the main content to have whatever outline the author was going for in the first place. Article is also seen has having hazy use cases: people are using them for everything. If you think about it, an article can be almost anything: people are sometimes using them for blog comments. Each comment an article? For some, why not? For others, wtf? Lastly, using a separate <main> element meant this element, meant to be used once per page (since that’s usually the case), can be mapped to the role of main natively. A native role means the element itself has that role by default (elements can have multiple roles). In the above example HTML, the main element would not need a role of main, and the nav element would not need a role of navigation. The other elements would need authors to specify their roles since not all headers would be the banner (there should be only one banner) etc. The advantage of native mapping then is users can get the benefits of roles even if the authors didn’t manually add them in.

I’m also quite confused as to why we need this element, a simple div with a role of main is sufficient enough to let the browser know what the element contains within it, I understand that it might be more clear to some that main wraps the bulk of the page content but I could see it been easily abused like <article> and <section> where its used everywhere the name fits but not semantic to the context it sits within.

Personally I would never use this element as it would offer no more semantic value to the page let alone screen readers are still trying to catch up with HTML5 to get a better experience to visually impaired users.

Just my 2 cents.

This is very possible if Hixie’s proposal that there can be more than one <main> per document gets traction. The original idea is that, like <nav>, there is only one per document or application.

The role was proposed first, and then had no particular element to whom it would be assigned natively.

…a simple div with a role of main is sufficient enough to let the browser know what the element contains within it…

It allows the browser to pass that on as a landmark to AT. However not all software accesses the accessibility layer of a browser. Native roles should be accessible to all software that accesses the HTML.

Most developers do not add roles to their markup. If they use a <nav> tag appropriately on a web page, or a <button> tag appropriately, or a <form> appropriately, they are automagically giving the correct semantic roles to AT and others: navigation, button, form. A role sets the states an element can have, can help set how an element may be interacted with, in addition to semantics.

ARIA roles are actually meant to be a stop-gap measure, to make up for defects, faults and missing semantics in HTML. Ideally, there would be no author-added ARIA roles (or so they say; I don’t actually believe this, because I believe there are going to be so many edge-cases and whatnot where an author who knows better will simply have to manually set roles… especially on applications and desktop-emulating web software). Whenever you have an element you can map a native role to, you increase accessibility and semantics without the legions of web developers having to do the “extra work” that they don’t do anyway.

let alone screen readers

In order for screen readers or any other AT to make any use of this element, they MUST rely on it being passed on to them by the browsers. No browser support means no AT support.

It’s being implemented in Chrome and Firefox nightlies. So far as I know, M$ is in support but lord knows they’ve already got quite a list of things they have to get to. Opera has usually been an early bird with lots of things like new form control types so I’m optimistic. So long as the browser can pass <main>'s native role on to anyone, it will be available to any AT who already understand landmarks anyway.

The NVDA guys are in serious discussion with Steve and others about landmarks in general. JAWS has been keeping up with landmarks-- I could navigate by landmarks in version 10. VoiceOver for Mac has also been keeping up. The others, I dunno, except Window-Eyes is way behind everything HTML5-wise and I dunno about HAL and IBM’s thing. Dragon Naturally Speaking recognises roles, though junk like this won’t work:
<i role=“checkbox”></i>
There are issues with manually assigning roles to things which may already have native (and conflicting) roles. I believe (but need to talk to some people to clarify) that if a native role conflicts with an author-assigned role, that the author-assigned role is ignored.

There was initially a lot of pessimism when the element was first proposed, especially from Hixie who wondered why a new element was needed. Possibly part of the reason was the poor implementation of <section> and <article> elements.

Some more talking about the new element:
Bruce Lawson: http://www.brucelawson.co.uk/2013/the-main-element/
Filament group: http://filamentgroup.com/lab/the_main_element/
Silvia Pfeiffer: http://blog.gingertech.net/2012/11/28/the-use-cases-for-a-main-element-in-html/

Sitepoint itself finally has an article about it. http://www.sitepoint.com/html5-main-element/