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

84 Responses on the article “The main element”

Manuel Strehl says

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.)

    Steve Faulkner says

    @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.

Manuel Strehl says

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.

    Steve Faulkner says

    @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

    Steve Faulkner says

    @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?

    Steve Faulkner says

    @Bobby

    Dr. Rich wrote:

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

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.

Steve Faulkner says

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

Dityo Nurasto says

<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?

    Steve Faulkner says

    Hi Ian,
    The main element should be used to wrap the main content of the page, if that content is in an article element then wrap the main element around it.

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.

    Steve Faulkner says

    @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. :-)

    Steve Faulkner says

    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.

    Steve Faulkner says

    @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!

    Steve Faulkner says

    @IanP you don’t need article if it is only one instance, main is more useful to users in this case:

    For example:
    <header>
    <main>
    <h1>
    <p>
    <p>
    </main>
    <footer>

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

    Steve Faulkner says

    @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.

Léonie Watson says

@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.

    Steve Faulkner says

    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.)

    Steve Faulkner says

    @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.

    Steve Faulkner says

    @Karl I am doing some grepping of a new data set to look at use of class=main , here is what I based main on:

    In the process of developing the

    element spec I looked at
    data from a number of sources [3] on frequency of usage of id values to
    indicate the main content area of a web page.
    I also used data I gathered in April 2012 based on a URL list of the
    top 10,000 most popular web sites.

    In preparing the data I sub setted the total usable HTML documents
    (approx 8900 pages – the home pages for sites in the top 10,000 URLs list )
    by searching for the use of the HTML5 doctype (approx 1545 pages). I
    figured that documents using the HTML5 doctype would provide the freshest
    code.

    What is apparent from the home page data in the sample:
    * use of a descriptive id to value to identify the main content area of a
    web page is common.
    (id=”main”|id=”content”|id=”maincontent”|id=”content-main”|id=”main-content”
    used on 39% of the pages in the sample )

    * There is a strong correlation between use of role=’main’ on an element
    with id values of ‘content’ or ‘main’ or permutations. (when used = 101
    pages) 77% were on an element with id values of ‘content’ or ‘main’ or
    permutations.
    * There is a strong correlation between use of id values of ‘content’ or
    ‘main’ or permutations as targets for ‘skip to content’/'skip to main
    content’ links (when used = 67 pages) 78% of skip link targets # were
    elements with id values of ‘content’ or ‘main’ or permutations.
    * There appears to be a strong correlation in the identification of content
    areas (with id values of ‘content’ or ‘main’ or permutations.)

    source: http://lists.w3.org/Archives/Public/public-html/2012Oct/0109.html

Ian Hickson says

@Karl I don’t recall studying id=”" vs class=”" (I don’t think it would tell you much). I do recall studying lots of randomly selected pages and finding that a huge number have multiple elements with classes or IDs like “main” or “content”, etc.

Nobody is suggesting everything should be <main>, only that there are cases where there’s more than one place that, if any is to be marked up as “main”, should be marked up as “main”.

Note that IMHO, and based on data collected prior to Steve’s advocacy on the subject, there’s really no need for this element at all. HTML already supported all the uses cases of role=main, better than role=main does. The only reason the WHATWG spec has the element at all is that multiple browsers implemented it.

Léonie Watson says

@Hixie
“Obviously you can make a page less accessible by having dozens and dozens of landmark roles — this isn’t specific to , you could just as
easily make a page suboptimal by having dozens of role=navigation () landmarks.”

True enough. At least in the case of nav, both specs advise using it only for major blocks of navigation. That’s only one element, and it’s not foolproof, but it helps.

Thinking about the multiple main model, I wonder whether it blurs the line between section and main too much? From an AT user’s point of view, a page with multiple instances of main wouldn’t be any more meaningful than a page with multiple section elements. It all hinges on the value of being able to determine which is *the main content of the page.

Karl Groves says

@Steve, your findings WRT the justification for <main> are similar to my experiences in doing manual code review over the last 10 years or so. There’s typically one distinct region in the document structure that is identified as the main unique content area of the page.

@Leonie, I agree with the possible muddying of waters between main and section. Multiple mains may as well be sections, IMO

    Steve Faulkner says

    @karl

    new data I recently gathered on use of role=main and the main element further supports the view that developers/authors working definition of main matches the W3C HTML definition. It’s a simple concept that developers grok. Its correct use is further supported by the conformance rules implemented in the W3C HTML validation service. So lively discussions aside I am confident that the main element will be useful and in the majority of cases used as specified in HTML5.

Ian Hickson says

@Léonie The main element is distinct from the section and article elements in that the main element does not contribute to the document outline. Generally, I’d expect the main element to be used to wrap the contents of a sectioning or sectioning root element (like <section>), just like people often use a <div class=body> (or contents, or main, or any number of other similar class names) today for that purpose.

    Steve Faulkner says

    @Hixie

    Generally, I’d expect the main element to be used to wrap the contents of a sectioning or sectioning root element (like <section>), just like people often use a <div class=body> (or contents, or main, or any number of other similar class names) today for that purpose.

    From looking at publicly available data sets I am not seeing the markup patterns you describe being used for the purpose you describe. Can you share some data with us to illustrate the basis for your assumptions?

Cliff Tyllick says

According to Mr. Hickson:

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. :-)

“(T)wo specs have diverged.”
Funny; I thought one reason to drop the “5″ from HTML5 was that there was to be only one—so, for example, DOCTYPE specifications could be set to “html” because there would be no other spec.
But now we have two.
For simplicity, perhaps we should come up with a more compact set of names for the two specs:

The W3C HTML WG HTML5 specification, which is determined by a working group’s deliberative review of facts and comments, with careful consideration of the effects of their decisions on people and the tools they use to experience the Web. I propose we call this spec “HTML5.”
The WHATWG HTML5 specification, which is determined by the whims of Ian Hickson, with random recollection of unspecified data gathered long ago and generally a refusal to consider any elements that don’t fit with that skewed view. I propose we call this spec “WHWTDHTML,” for “whatever @hixie wants to do” HTML.” Or “HTMLNSFRW,” for “HTML not suitable for the real world.”

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.

The only thing that would be obvious to me in such a situation would be that the page author and coder lacked the decisiveness required to identify the principal content of the page, so I would have to think about it and decide for myself.
Skimming the page shouldn’t require thought. Any good course in writing for the Web would tell Mr. Turley that.

    Steve Faulkner says

    @Cliff

    Whilst I appreciate your frustration let me make it clear that Ian has and continues to make a major contribution to the development of HTML. A lot of the specification work on main stream implementation of features is carried out by Ian via the WHATWG. Where the W3C is concentrating its efforts is on testing of HTML features for interoperability, ensuring accessibility is taken into account, defining the accessibility layer implementation requirements, providing an opportunity for development of new HTML features, further development and improvement of the semantics of existing features, improvement and additions to author advice and requirements.

    The W3C HTML specification includes much of what Ian proposes via the WHATWG, (The HTML editors cherry pick commits Ian makes on a weekly basis) but we reject or modify his proposals based on technical consensus via review of use cases, research and data (for example Ian’s proposed changes to the figure element definition and advice have just been added to the HTML 5.1 editors draft for review. I have emailed the HTML working group to gather feedback.) Ian is a major contributor to HTML but does not have the last word on the specification of HTML, which is understandably frustrating for him. Which I think is the basis for much of the discord, but its something we have to live with, the development of web platform for the good of all is much more important that the appeasement of one individual.

    It should also be noted that many of the same people who participate in the W3C on development of web standards also participate in the WHATWG, it is in no way 2 distinct camps. There is an ideological schism between certain individuals in regards to the dictatorial approach favoured by Ian versus the technical consensus approach of the W3C. In the case of the main element, for example it wouldn’t exist if it weren’t for the W3C as Ian rejected it in his role as decision maker at the WHATWG. It was only due to the W3C that I was able to develop and specify the feature and gain support for its inclusion in HTML.

    I talk more about such stuff in this interview

Léonie Watson says

@Hixie
“@Léonie The main element is distinct from the section and article elements in that the main element does not contribute to the document outline. Generally,
I’d expect the main element to be used to wrap the contents of a sectioning or sectioning root element (like ), just like people often use a (or contents, or main, or any number of other similar class names) today for that purpose.”

Using the dataset that Steve references [1], implementing the main element as you suggest (as an equivalent to a div with class of content/main etc.) seems to support the notion of a single instance of main per page doesn’t it?

[1] http://lists.w3.org/Archives/Public/public-html/2012Oct/0109.html

Ian Hickson says

@Léonie Sure, most of the time you’ll only have one, like you’d only have one <footer> or one <header>.

mattur says

Cliff Tyllick:

You’ve missed the point: it’s still “programmatically obvious” where the principal content begins in this scenario even with multiple main elements, so this is not an argument for requiring only one main element per page. There may well be other arguments for only allowing one main element per page, but this is obviously not one of them.

Also see the W3C WAI-ARIA1.0 spec for an example of multiple role=main’s in one page: role=main is currently allowed multiple times when in separate document and application regions, though this could change in ARIA.next. Nothing to do with “decisiveness”. Read the spec:

http://www.w3.org/TR/wai-aria/roles#document
http://www.w3.org/TR/wai-aria/roles#main

    Steve Faulkner says

    @mattur,

    The definition of main proposed by Ian does not identify the main content of the document, so cannot be used as a programmatic indicator of the main content of the document or indeed as the main content of anything.

Ian Hickson says

Uh, yeah it does. You’re welcome to your opinion of how best to help authors use the element, but please don’t just lie about what other specs say.

    Steve Faulkner says

    Classy, you respond to accuse me of lying, but can’t respond to provide evidence for your unsupported assertions about what benefits users and the markup patterns used by developers.

    Your (WHATWG) definition of main:

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

    similarly

    The HTML specification definition of the div element

    The div element has no special meaning at all. It represents its children.

    The HTML spec definition of main:

    The main element represents the main content of the body of a document or application.

    The definition of represents

    Elements in the DOM represent things; that is, they have intrinsic meaning, also known as semantics.

    Will leave it up to others to draw their conclusions about whether I was lying…

Ian Hickson says

@Steve: Dude, if you’re going to edit the spec, please for the love of kittens at least read it. If the <main> element didn’t represent its children, then it would be like if it was set to display:none. “main content” and “dominant contents” mean the same thing. Using “main content” in the spec would be bad style since it would mean defining an element using the same word as the element’s own name, which we try to avoid.

@Everyone else: I’m done with this conversation; every time I try to reply to someone’s comments, Steve snipes in. If anyone else has any feedback on the WHATWG spec, please don’t hesitate to send it in at http://whatwg.org/html or e-mail me directly at ian@hixie.ch or post to the WHATWG list: http://whatwg.org/mailing-list

    Steve Faulkner says

    Dude, if you’re going to edit the spec, please for the love of kittens at least read it.

    Dude, if you’re going to spec features, please for the love of kittens provide use cases, data, and talk to real users and developers.

Bertilo Wennergren says

The division of HTML5 in to two competing standards (and also the quarrel we just witnessed) is really really bad. Stop it!

Reinier Kaper says

I’m happy to see this element added to the spec and thanks Steve for your hard work on this topic!

It makes a lot of sense to have a <main> element to explicitly indicate where the… well… main content of your page/app lives ;-)

I’m also happy with the actual spec (a unique element). Although we’re allowed multiple headers, asides and footers I guess you’d lose semantic value if you’d be able to repeat main’s and/or body’s as well.

On a side-note: I’m not entirely sure what the ‘use’ of two different specs is. I understand there are differences in opinion that lead to these specs, but what’s the benefit (or harm) to developers and end-users?

Are browser vendors picking their ‘favourite’, or is it more of a personal battle thing? ;-)

Also, is it still advisable to add the ARIA role to the main element (for older browsers perhaps)?

Anyway, thanks again, I truly believe all aspects of HTML5 are moving the web forward at a great pace, keep it up!

    Steve Faulkner says

    @Reinier,

    Glad you see the utility of the new element :-)

    I’m also happy with the actual spec (a unique element). Although we’re allowed multiple headers, asides and footers I guess you’d lose semantic value if you’d be able to repeat main’s and/or body’s as well.

    Agreed and I think it would make it less likely that it is used for the primary use cases.

    On a side-note: I’m not entirely sure what the ‘use’ of two different specs is. I understand there are differences in opinion that lead to these specs, but what’s the benefit (or harm) to developers and end-users?

    There is only one HTML specification which is maintained by the W3C, and multiple editors drafts (W3C and WHATWG) I talk more about it in this interview.

    Are browser vendors picking their ‘favourite’, or is it more of a personal battle thing? ;-)

    Depends on the browser vendor and which developer from the respective browser vendor. All of the major browser vendors participate and are active in the development of the deliverables (which include HTML5 and HTML 5.1) of the HTML working group. Most browser vendors also participate in the WHATWG.

    Also, is it still advisable to add the ARIA role to the main element (for older browsers perhaps)?

    Yes, although the main element has built in mapping to main role in browsers that have implemented it, the implementation across browsers is not complete (like for most new features in HTML5). This recent article 5 HTML5 and ARIA design patterns may be helpful.

Reinier Kaper says

@Steve

Thanks for the replies and clearing up the whole spec/drafts thing. I never fully understood that structure ;-)

It’s kind of a shame that, in an effort to make the web a better place, there’s no real consensus.

I’m not at all familiar with the history behind it all, but it almost feels like someone (or some individuals) decided to start their own gig, instead of putting their effort in a central area.

I will read through your interview as well to learn a little bit more about this ‘issue’. Who knows, maybe I’ll get involved ;-)

Abaloo says

For the love of kittens, do you guys realise how ridiculous this bitching sounds? @Hixie your passive aggressie tone throughout makes me feel sick – this isn’t some boy’s toys game. It’s the spec that impacts billions of people on perhaps the most important technology of our time.

I’m with Steve on this, but for God’s sake sort it out…as not on a public forum where anyone reading the comments on this article probably leaves feeling more confused than if they’d never tea the article at all.

It’s like 1996 all over again.

Lynn Holdsworth says

At long, long last! A foolproof way for AT to know what constitutes the main content of a page. Thank you so much Steve for the massive research and effort
you always put into making the spec better for AT users. It’s very much appreciated.
Where Hixie says “Pick whichever spec you think is more useful. :-)”, can we change that to a :-( ? This <main> pollution will totally scupper the effectiveness
of this great new tag that could make such a positive difference to me and other AT users. Why not continue to use <article> instead? It seems perfectly adequate
for the job.

Kay says

Edit:

Oooops! I forgot to use > for my tags -_______-
Please delete my previous comment!

Here the updated version with proper mark-up:

Hi HTML5 Doctor team!
You wrote “Of course, if you use the html5shiv, is now baked in directly.” but I can’t get it working in ie8. An actual version of Modernizr (2.6.2) is implemented and works well with tags like <nav>, <section> , etc..
I even put an additional query of html5.js from google in my <head> but ie8 doesn’t recognize any styles on my <main>tag.

May I ask you if you have any recommendations for me?

I don’t want to use the old div.main ^___^

Mario Cisneros says

@Kay I use Modernizr (2.6.2.) too instead of html5shiv and simply updated the string associated with the var html5 = { } starting on line 1245 by adding main between hgroup and mark and my site rendered correctly in IE 7&8.

I really wanted to use this new element instead of and this update worked for me. Of course, I added the new element to my reset.css file to display block.

    Kay says

    I’ll try that, Mario!
    Thanks for the help!

Don Ulrich says

Multiple “main” elements would not be atomic and would just be more clutter…more lines of code to charge back to the client. What is with the developers in England anyway? They almost crave turning everything into a complex liturgy. (see history) HTML SHOULD BE ATOMIC TO THE CONTENT IT REPRESENTS. Tiny not bigger or more clumsy. It is certainly not more semantic to add elements to say this is an “aside” but that is the nature of english in England. Funny how this semantic argument has roots that date back 500+ years. FYI aside is an adjective not a noun or object. Semantics, really?

Hopi says

I already implement ARIA roles like “banner” and “main” for accessibility purposes. I stay clear from HTML5 elements for accessibility, since support is still lacking and not consistent.

Only Window Eyes does not support any of the HTML5 elements (in any browser). VoiceOver, Jaws and NVDA all support some elements, but not always consistently across browsers.
[...]
all screen readers tested have good support for ARIA landmarks.

Is such a view to accessibility ok? That is: Use ARIA landmarks on div’s for maximum accessibility and support.

Tim E says

Does it make sense to put a main element within a main element? So you have a main element for the primary area of the site, but maybe that page has multiple areas within it that can be described with main?

    Steve Faulkner says

    Hi Tim, no main is for the primary content area of a page, subsections can be marked up using article, for example.

Andrew says

Steve is my hero for this.

The way I write my documents (very strictly structured, free of filthy DIVs if at all possible), I really needed this element. I have wondered for years why it was missing, and now that it has been brought to this world, HTML makes even more sense :)

And to think what we went through with XHTML… those were dark days. Dark, div infested days. It kills me to see some developers (and those bloated frameworks *cough* Bootstrap) are still using them nonstop and keeping the web in it’s current div-soup state.

Now that we have main, my current project’s lay0ut requires ZERO divs. The best way to build a responsive website, I’ve found, is not to use some messy framework, but to follow the HTML5 document structure naturally. Nesting is your friend!

Richard Clark says

Alice, main isn’t sectioning content, so it doesn’t make sense to add it to that flowchart.

Alohci says

@Richard – neither are div, p, pre, or address but they all get a mention. More to the point, <main> is often perceived by web authors as sectioning content and it’s often encouraged to be used in place of the mistaken use of section and article. The flowchart would be a great way of supporting that.

Alice M says

I am still a little confused about how to use this new element. If the purpose is for accessibility, wouldn’t it be wrong to include an aside sidebar with unrelated content in with the ‘main’ element?

It seems like it would be more semantic to have the aside outside of the main element as it is not truly the main content of the site.

Mike says

So is this an acceptable layout ?

body
- header
- main
– article
– aside
- footer

It seems the only way that makes sense to me (and indeed, it’s what html5doctor.com is using in their HTML). But comments above imply that <aside&rt; should not be wrapped by <main&rt;. If that’s the case, then there’s little real difference between <main&rt; and <article&rt; and it seems a missed opportunity. I suspect most sites will end up using main as a wrapper for both article and aside the same way this site is doing, as it seems most beneficial that way.

Sky Shabatura says

Crap, it ate my brackets.
I share the same confusion as the last two posters. I use two elements that both could be candidates for the <main> element.

header
div#main
- div#content
- aside
/div#main
footer

So, in this scenario, would it be preferable to have <main> as the outer wrapper that encompasses both #content and the aside,
or leave the wrapper as a div and make #content into <main>?

On the one hand, #content is really where the “main” content lives, but on the other, I like the organization of:

header
main
footer

I always want to call main “#body” to keep with the anatomical analogies (head, foot, what lies between?) but that’s too confusing. It would be equally confusing to have a <main> element and a separate div#main, so I suppose whichever one doesn’t become <main> will have to be div#content.

Thanks for the nice write up.

Jakob E says

1) If the primary purpose of <main> is to map ARIA’s landmark role main to an element in HTML – then why not add <banner> and <contentinfo>?

2) We still need an ID on main for the AT link “skip-to-main-content” <div id=”main” role=”main”> does the same and does not add to document outline either.

My point is tag-inflation is bad document.createElement(“letsgocrazy”) ;-)

    Steve Faulkner says

    1) If the primary purpose of

    is to map ARIA’s landmark role main to an element in HTML – then why not add <banner> and <contentinfo>?

    they are already there:
    footer element that is not a descendant of an article or section element.=contentinfo
    header element that is not a descendant of an article or section element.=banner

    2) We still need an ID on main for the AT link

    skip links are not primarily for AT users, they have heading and landmark navigation. skip links help keyboard only users, we are working on adding landmark navigation for keyboard users to browsers, so skip links will be redundant.

    My point is tag-inflation is bad document.createElement(“letsgocrazy”)

    see custom elements.

Jakob E says

Hi Steve,

Don’t get me wrong I’m not a main hater. I’m just advocating not to create bloat when it comes to standards – more options more confusion – less semantics.

The banner and contentinfo were ment to illustrate that maybe we should not mix HTML and WAI-ARIA but leave them to handle what each does best – avoiding assumptions that HTML will handle the accessibility (WAI-ARIA is Not not needed).

Thank you for taking your time :)
Jakob

    Steve Faulkner says

    Hi Jakob,

    we should not mix HTML and WAI-ARIA but leave them to handle what each does best – avoiding assumptions that HTML will handle the accessibility (WAI-ARIA is Not not needed).

    I think your view is erroneous, where author practice and accessibility complement each other its better to build accessibility in rather than bolt it on. ARIA is meant for cases where a feature does not have built in roles,states and properties that reflect its use. The majority of features have built in accessibility semantics, that is how users of assistive technology are informed about the UI. There has been a long tradition of authors using a <div> element to demarcate the main content of a document, which has also been used as the target of a skip to main content link and more recently as the host for role=main. All the formalization of the main element has done is make it easier for authors to do something they were already doing.

Jakob E says

Hi Steve,

The reason why I’m confused is that the implementation of main still requires role=”main” (apart from being a total ARIA newbie).

The header role=”banner” makes sense as it takes a special role outside a section or article (same goes for contentinfo) – as you pointed out.

When do we need to add a landmark role to provide a fallback (I guess that’s the reason for keeping it on main). Do we need to add role=”complementary” on asides and article footers
as I’ve seen suggested doing my googeling (group as well)?

If you ever have a spare moment I would love to see an article (role=”article” ?) on this topic :)

    Steve Faulkner says

    Hi Jakob,

    The browser accessibility implementation story for a slew of new HTML features is recorded on HTML5 accessibility (on github). Note I am in the process of updating the info, so no current Mac browsers are listed. The recommendations table in Using ARIA in HTML provides guidance on the question “Should authors explicitly define default ARIA semantics?” for all HTML features. But in general as the HTML spec says:

    In the majority of cases setting an ARIA role and/or aria-* attribute that matches the default implicit ARIA semantics is unnecessary and not recommended as these properties are already set by the browser.

    It is only necessary for newer features that have not had their accessibility support built in yet by browsers. (main being an example)

Sky Shabatura says

Regarding Alice M, Mike, and my own questions above:

I’ve been reading over the draft for the last week, and this is what I’ve taken away from it.

The main content area of a document includes content that is unique to that document and excludes content that is repeated across a set of documents such as site navigation links, copyright information, site logos and banners and search forms (unless the document or applications main function is that of a search form).

In my experience, an aside usually contains widgets that are in scope to the entire site, and not necessarily to the specific page’s content. In this case, the aside belongs outside of main.

If, on the other hand, the content in the widgets is specific to the page on which it displays and is related to that page’s content, then it belongs inside main.

Dan G says

Hi, thanks for the great info. I’m not sure if people are still actively commenting and reading the comments but I have a quick question. Since main is now put into the html5shiv, that (hopefully) means it’s here to stay.

So, say I’m creating a website. Could I use main

for my page wrapper instead of div

As long as only consists of sections, articles, and asides?

Something in the likes of.


<header>
......
</header>

<main id="wrapper" role="main">
<section>......</section>
</main>

<footer>

</footer>

Would that be semantic or keep using div as the page wrapper.

    Steve Faulkner says

    Hi Dan,

    Since main is now put into the html5shiv, that (hopefully) means it’s here to stay.

    The main element is implemented along with its semantics (role=main) in all major browsers except IE (IE is the reason why it is still suggested to ad explicit role=main), so it is here to stay.

    main is the container for the main content of the page, so in your example code you are using it as it should be used.

Lynda S. says

Question:

As you mentioned in your article the main element cannot be a descendant of an article, aside, footer, header, or nav element.

My question is can I wrap the main element in a div?

I ask because I would like to box the page content as the page will have a background but I want to box the header, main and footer elements. If I do this will it be valid in regards to the main element (and for that matter the header and footer as well.)

Thank You for the great information!

    Steve Faulkner says

    My question is can I wrap the main element in a div?

    yes

Join the discussion.

Some HTML is ok

You can use these tags:
<a href="" title="">
<abbr title="">
<b>
<blockquote cite="">
<cite>
<del datetime="">
<em>
<i>
<q cite="">
<strong>

You can also use <code>, and remember to use &lt; and &gt; for brackets.