The main element

by .

Recently, <main> was formally added to the W3C HTML specification. Now that the dust has settled, it’s about time we dive in to find out where and when it’s appropriate to use <main>. Let’s get started.

History

The inclusion of a main element (or similar) has long been debated in the working groups with authors and others often questioning why we had new elements such as <header>, <article>, and <footer> but no element to accurately describe the primary content of a page.

Steve Faulkner, an accessibility consultant and new doctor in residence, undertook the hard graft of carrying out research, gathering data and use cases, and speaking to implementers to get them interested. As Steve explains, he talked to:

as many implementers (both general browser implementers and accessibility implementers), developers, authors and users as I could and got advice and input from them. I went where the various people hung out; on IRC, mailing lists, twitter, blogs, conferences — anywhere.

This led to his writing an extension specification for <main> and a thorough use case rationale.

The proposal was accepted in November 2012, and <main> was then rolled into the HTML5.1 specification. Recently, it was added to the HTML5 specification following no objections. Lets have a look at how the spec describes <main>.

W3C Specification

The primary purpose of <main> is to map ARIA’s landmark role main to an element in HTML. This will help screen readers and other assistive technologies understand where the main content begins. The W3C spec describes <main> as representing:

The main content of the body of a document or application. The main content area consists of content that is directly related to or expands upon the central topic of a document or central functionality of an application.

Since the <main> element is now included in the HTML specification, the <body> element has reverted to its HTML4 definition:

The body element represents the content of the document.

More Details

One important facet of <main> is that it can only be used once per page. Jeremy Keith wrote to the working group to understand why this is the case (rather than allowing multiple <main>s). Although I won’t go into detail, the discussion is an interesting read.

As per the spec, the W3C validator throws an error if you attempt to use multiple <main> elements per document.

Another stipulation of <main> is that it can’t be used as a descendant of an <article>, <aside>, <footer>, <header>, or <nav> element.

Because <main> isn’t sectioning content, it doesn’t affect the document outline in the same way <article>, <nav>, or <section> do.

Getting Going

Just as with the introduction of many other new HTML5 elements, not all browsers recognise <main> or have preset styles for it. You’ll need to ensure it displays as a block level element in your CSS:

main {display:block;}

For the time being, you'll also need to use JavaScript to create the element for older versions of IE:

<script>document.createElement('main');</script>

Of course, if you use the html5shiv, <main> is now baked in directly.

Implementing <main> on HTML5 Doctor

The easiest way to implement <main> is to replace that <div> that you've likely got with an id or class of something like main or content.

So what does that look like in practice? Well, here's our pre-<main> markup on HTML5 Doctor:

<body>
<header role="banner">
[...]
</header>

<div id="content" class="group" role="main">
[...]
</div>

<footer role="contentinfo">
    [...]
</footer>
</body>

And here's what it's like now:

<body>
<header role="banner">
[...]
</header>

<main id="content" class="group" role="main">
[...]
</main>

<footer role="contentinfo">
    [...]
</footer>
</body>

Yes, it's really that simple. With any luck, it'll take you less than five minutes to implement.

The WHATWG Version

The WHATWG definition of <main> differs from the W3C version in that the element has no meaning. It's merely a styling hook (like a <div> with a new name) and represents its children.

The main element can be used as a container for the dominant contents of another element. It represents its children.

We recommend using the W3C version of <main> as described above.

Browser Support

Firefox 21, Chrome 26, and a WebKit r140374 have all implemented basic support for <main>.

They have all mapped the ARIA role="main" to the <main> element so assistive technologies can now recognise the <main> element without issue.

Summary

As you've seen, it's super easy to get up and running with <main>. It only takes a few minutes, so now really is the time to start adding it to the sites you're developing.

If you aren't sure when or where to use <main>, be sure to ask us in the comments and one of us will try to help you out.

Further reading

106 Responses on the article “The main element”

  • I’m not fully sure, why <main> may not be a descendant especially of article. IMHO one quite common use case looks like this:

    body > article > {header, div#main, aside, footer}

    In this case it’s forbidden to replace div#main with a main element, if I read it correctly. This limits the use of main hugely, if for whatever reason the header and footer are not part of the main content.

    (One could of course argue, that then the parent should not be an article.)

    • @manuel,
      The use of main is restricted because it has a strong semantic meaning which is conveyed to users. From reviewing the use of id=main (and the like) in thousands of pages I did not see the pattern you describe. Have a look at how article is used in a sample of 170 pages using it. So while the use of main is restricted I don’t consider it “limits the use of main hugely” for the identified use cases it was designed for. But if you have new data to support your use case please do file a bug on the HTML spec.

  • Thanks for the answer. No, I have no data to support my claim. It was just what I thought of seeing as not unusual pattern (also when looking over my own shoulder, so to say). Actually, writing my question and reading your answer clarified the purpose of the article element more to me.

  • AA Studio says:

    Once all modern browsers support , will it be possible to simply write your example like this ?


    <main>

    (I meant to remove role="main" ?)

  • Dahl says:

    About what @manuel said about the structure:
    body>article>{header, main,aside,footer}.

    I think the reason we haven’t seen this structure used widely before, is the simple fact that nobody had the new html5 elements to use. So I’m not really convinced.

    • @dhal

      There are millions of pages using article header, aside, footer. What is not a common pattern is to wrap the whole page in an article. here are some numbers from a data set of just 53,000 pages:

      Number of pages using element – header: 5975, footer: 6025, aside: 2333, nav: 5315, section: 4112, article:2674

  • Ian Hickson says:

    @manuel You can do that, that’s exactly what the WHATWG spec’s definition of is intended for (replacing ).

    For people interested in the rationale for the difference between the W3C’s definition and the WHATWG’s, see the discussion here:
    https://www.w3.org/Bugs/Public/show_bug.cgi?id=21553

    • @Ian

      I reviewed your proposed definition of main at the time you added it, I also asked on your mailing list for Rationale? use cases? and data? for your recasting of main, to date there has been no reply. I followed the discussion in the bug you cite, but found it did not contain much in the way of useful rationale, use cases or data, only restatements of the same arguments you made and that were rejected in the discussion of main on the whatwg list. But if you do have new information, I strongly encourage you to file a bug on the HTML spec.

  • Bobby says:

    What about HTML5Shiv? does it support (create element) for <main> element?

  • Alohci says:

    Having read through the bug thread Hixie links to, I can’t help feeling that the WHATWG definition is liable to create a mismatch between web author expectations and AT user expectations.

    The definition says “The main element can be used as a container for the dominant contents of another element.”, and doesn’t say anything about what that other element is. As a web author, using analogy with header and footer, I took this mean that the main element indicated the dominant content of its nearest ancestor sectioning content element. It could therefore be used *or not used* with impunity anywhere to indicate a section or article’s dominant content but there was no requirement to apply such containers consistently. This means that main elements could end up dotted over a document in a selection of sectioning elements at various levels. Again, there’s nothing in the WHATWG definition to say that’s wrong.

    But in the bug thread, Hixie seems to be arguing for something else. It seems that AT will treat the main elements as peers. That on stepping over the loop of main elements will take the user to various parts of the dominant contents of the *body element*.

    So the expectation of the AT user is that they will jump to the first main element and get to the first non-crufty content of the document. They consume some or all of that, then jump to next main element to get the next non-crufty content at approximately the same level of detail. But it the web author has marked up the page as described above, that’s not what they’ll get. What they’ll get is a jump to the content of some arbitrary internal section of the document, covering some relatively minor detail. And similarly for each further jump until it loops back to the top.

    Given that AT it seems is required support marking multiple blocks of content with a role of main, and that the main element, in the light of the WHATWG spec, will probably be used to mark the dominant content of articles and sections at any level, I wonder whether it might be a good idea if the main element was only mapped to the main role if either (a) the main element does not have a main element ancestor, or (b) the main element does not have a sectioning content ancestor.

    Otherwise, it would be useful if the WHATWG spec was adjusted to make it clearer what the consequences were to AT users of marking up the dominant contents of sectioning elements as main elements.

  • Hi Alohci,

    the WHATWG definition is liable to create a mismatch between web author expectations and AT user expectations.

    I agree, but lets be clear, the whatwg definition of main is something hixie made up after main as specified was implemented. without any discussion or provision of uses cases, data or consultation with users, developers or implementers. It’s a proposal that has been rejected, it only lives on in the whatwg spec because hixie decides what’s in his spec.

    I have been watching closely how usage of main is being reported to developers and how it is being used. Early data strongly suggests that it is being used and is understood as per the HTML spec.

    This is unsurprising as the element was developed by looking at how authors markup the main content of a page using id’s and how they use role=main. It was also developed by talking with users about what would be most useful to them. main paved a useful and long trodden cow path.

    I will be monitoring usage over the next few years and if it is found that usage differs widely from what is specified it will make sense to revisit and review the implementation and authoring requirements.

  • Ian Hickson says:

    @Alohci: That’s an interesting point. If you’d like the spec updated to disallow nesting of main elements, please don’t hesitate to file a bug: http://whatwg.org/newbug

  • <main> element should be exist because when I was created a HTML 5 document I always wonder if there’s any semantic tag to the content it self since header and footer is allowed for the body.

    I saw in HTML 5.1 nightly build about the <main> which only allowed once and must direct descendant of the body. This is great to complete the puzzle.

    This will make clarity especially to the use of confusing elements like section, article and aside.

    I am very pleased with <main> inclusion. HTML5 Document hierarchy is easy to understand now.

  • Ian P says:

    I’ve been lead to believe that often it’s wise to use <article> when the main piece of content is something that can be displayed on it’s own, in isolation. For example, a ‘single’ blog post on it’s own page – the bulk of the content should be in an <article> tag.

    This seems quite common in WordPress themes.

    What is the recommendation now? Wrap a main in an article, vis versa? Pick one over the other?

  • Ian Hickson says:

    @IanP That’s still the right thing to do. The <main> element just adds a way for you to replace <div class=”main”>, in case you were doing that before to e.g. wrap the contents of the article that weren’t the header or footer.

    • @Ian,

      The <main> element just adds a way for you to replace <div class=”main”>

      Incorrect; the main element allows you to replace a <div id="main"> with an element that has a clear and useful meaning to users who actually consume the semantics.

  • Ian Hickson says:

    Where Steve says “incorrect”, he means this is an example of where the two specs have diverged. Pick whichever spec you think is more useful. :-)

    • Where Steve says “incorrect”, he means this is an example of where the two specs have diverged.

      No, I mean that it is incorrect because it will lead to a less useful user experience.

      Pick whichever spec you think is more useful.

      to end users…

  • WraithKenny says:

    Couldn’t a contextual switch be a compromise of the two specs?

    The WC3 version requires not to be nested to an , , , , or element, and that it be Unique.

    If nested elements are ignored (as opposed to being an error) for the purposes of the W3C spec, which is to say, the Uniqueness of the non-nested element is what is important for establishing it’s role as a landmark role, then the ignored nested, (and non-unique) s can be used as described by Hickson.

    • @Kenny,

      We think its best to keep the rule on use strict and simple. Why do we need another element to use, that does not convey useful semantics, which only acts as a shorthand for a styling hook? That is what <div class="main"> is for. Muddying the waters by changing its meaning depending on context and allowing practically unfettered use is not supported by any use cases provided, but if you have new data/use cases please do not hesitate to file a bug on HTML 5.1.

  • Ian P says:

    @Steve Faulkner ,

    Cheers. End users are my priority here, as I’m styling to classes rather than to the elements themselves. I’m not convinced that adding an extra element around another makes things better.

    I’ve previously been using when relevant, but I’m a little unsure now!

  • Ian Hickson says:

    Note that nothing in ARIA prevents multiple elements from having the same landmark role. The WHATWG definition is just as accessible as Steve’s — more so, arguably, since it allows for the user to skip past inner bits of the content that aren’t “main” content (I’ve often seen articles have “skip to next paragraph” links around ads; that could be handled using <main> on either side of the ad, for instance).

    As I mentioned earlier, this is discussed in some detail in this bug report: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21553

    • @hixie

      There is a normative should be nor more than one requirement for main, header and footer in ARIA.

      Within any document or application, the author SHOULD mark no more than one element with the main role.

      The WHATWG definition is just as accessible as Steve’s

      It’s not ‘Steve’s definition’ it’s the definition in HTML which has been discussed, reviewed and agreed to by the W3C HTML WG, as against the WHATWG definition which is decided by you only, right :-)

      more so, arguably, since it allows for the user to skip past inner bits of the content that aren’t “main” content (I’ve often seen articles have “skip to next paragraph” links around ads; that could be handled using

      on either side of the ad, for instance).

      It’s unfortunate that your understanding of the features of AT is limited, users already have a plethora of methods to navigate smaller chunks of content: they have keystrokes to navigate paragraphs,headings, lists, tables, table rows, images, articles, forms, form controls, link, fieldsets, frames etc. What they have indicated when talking to them is that the utility of landmarks decreases as a function of the number, the more there are the less use they become. Landmarks are macro navigation tools.

      But if you have data that shows users want more micro navigation such as you describe, please provide it, at the W3C we are more than willing to change the HTML spec to improve users experience.

      As for the bug report you cite repeatedly, do you have any use cases or data? thought experiments are not much use.

  • As a practical aside, my colleague Matthew Atkinson has further developed the Firefox Landmark Navigation Extension to support the implicit semantics of header, footer, aside, main and section.

  • @Hixie
    “The WHATWG definition is just as accessible as Steve’s — more
    so, arguably, since it allows for the user to skip past inner bits of the content that aren’t “main” content (I’ve often seen articles have “skip to next
    paragraph” links around ads; that could be handled using on either side of the ad, for instance).”

    At first glance this looks like a viable approach. I think it’s actually an idea that looks better than in theory than it’s likely to be in practice though.

    Screen readers already have native features that make it possible to bypass chunks of content or navigate through them. Introducing skip links or multiple main elements to make this possible isn’t really nescessary.

    Landmark navigation is one such feature. Too many landmarks on a page is counter-productive though. Cycling through lots of landmarks is inefficient for keyboard users, and too many of the same landmark rapidly reduces the semantic value of each one.

    One thing screen reader users can’t do is determine where the principal content of the page starts/ends. Visually it’s obvious, and a single instance of main makes it programmatically obvious too. Multiple instances of main counteract this benefit though.

    It would be possible to distinguish one instance of main from another using aria-labelledby or aria-label, but this places an extra burden on the developer. Besides, it doesn’t solve the physical interaction problem of cycling through multiple landmarks to get to the one you’re after.

    The advertising problem you mention above could also be addressed in other ways, without resorting to multiple instances of main. It depends on the content surrounding the advertising of course, but instead of using main the article or section elements could be used, or divs with headings (to name a couple of possibilities).

  • mattur says:

    One thing screen reader users can’t do is determine where the principal content of the page starts/ends. Visually it’s obvious, and a single instance of main makes it programmatically obvious too. Multiple instances of main counteract this benefit though.

    It’s still programmatically obvious where the principal content begins even when there’s more than one main element on the page: it begins at the first main element.

    • If the main element has no mapping to role=main and does not represent the main content of the document, as it is defined by Ian, then it does not provide a method to identify the main content of of the page. It’s the same as saying <x class='main'> identifies the main content of the document.

  • Ian Hickson says:

    @mattur The problem is many pages have multiple sections that are “main” content, separated by “non-main” content. Sometimes the parts of main content are quite far apart, even. This is why the WHATWG spec allow multiple <main> elements (which are mapped to role=main, which ARIA allows to occur in multiple places in a file, with only a “should”-level requirement to restrict it to one per subsection marked with role=document or role=application, nothing on a per-page basis, and no “must” requirement at all).

    @Léonie Obviously you can make a page less accessible by having dozens and dozens of landmark roles — this isn’t specific to <main>, you could just as easily make a page suboptimal by having dozens of role=navigation (<nav>) landmarks. The UI to navigate between those and main landmarks is (or at least, can be; there’s no spec that requires any particular UI) the same.

    (I’m not responding to Steve any more since he’s obviously just trolling me with statements he must surely know are incorrect.)

    • @Ian

      (I’m not responding to Steve any more since he’s obviously just trolling me with statements he must surely know are incorrect.)

      You haven’t actually responded to any of my questions anyway, I have and continue to try to get a straight answer and some evidence for your assertions. The main element as defined in the HTML spec is based on publicly available and verifiable data of existing author usage, browser and AT support of HTML and ARIA (Rationale and use cases for standardizing a ‘main content’ HTML feature), what have you provided?

  • Karl Groves says:

    Ostensibly, much of what has been added/ changed in HTML5 was born by “data” indicating rather ubiquitous development paradigms across the Web. Mr. Hickson’s decision making process throughout development of WHATWG’s HTML5 specification has been based on this “data”. Much of it, admittedly, has been agreeable, but at times this “data” (not shared with others, AFAIK) has been used to justify why a decision was made not to include certain features.

    In this case, regarding whether or not it is appropriate to have multiple ‘main’ elements, I’m wondering if Mr. Hickson has data to share that would substantiate the implicit claim that class="main" is more commonly found throughout the web than id="main".

    Semantically, the meaning of “main”, to me, seems clear as evidenced by a simple search on Google: https://www.google.com/search?q=define%3Amain

    Chief in size or importance: “a main road”; “the main problem”.

    Synonyms: principal – chief – cardinal – capital – primary – prime

    There’s a phrase I once heard that says “When everyone gets a trophy nobody wins” which I think in this case can be rephrased as “When everything is <main>, nothing is.