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.
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
mainis restricted because it has a strong semantic meaning which is conveyed to users. From reviewing the use ofid=main(and the like) in thousands of pages I did not see the pattern you describe. Have a look at howarticleis used in a sample of 170 pages using it. So while the use ofmainis restricted I don’t consider it “limits the use ofmainhugely” 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
articleelement more to me.Once all modern browsers support , will it be possible to simply write your example like this ?
<main>
(I meant to remove
role="main"?)yes
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
@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
mainat the time you added it, I also asked on your mailing list for Rationale? use cases? and data? for your recasting ofmain, 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 ofmainon the whatwg list. But if you do have new information, I strongly encourage you to file a bug on the HTML spec.What about HTML5Shiv? does it support (create element) for <main> element?
@Bobby
Dr. Rich wrote:
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,
I agree, but lets be clear, the whatwg definition of
mainis something hixie made up aftermainas 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
mainis 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.mainpaved 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.
@Alohci: That’s an interesting point. If you’d like the spec updated to disallow nesting of
mainelements, 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.
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?
Hi Ian,
The
mainelement should be used to wrap the main content of the page, if that content is in anarticleelement then wrap themainelement around it.@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,
Incorrect; the
mainelement 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.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. :-)
No, I mean that it is incorrect because it will lead to a less useful user experience.
to end users…
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.@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!
@IanP you don’t need
articleif it is only one instance,mainis more useful to users in this case:For example:
<header><main>
<h1>
<p>
<p>
</main>
<footer>
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,headerandfooterin ARIA.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 :-)
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, mainandsection.@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).
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
mainelement has no mapping torole=mainand<x class='main'>identifies the main content of the document.@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
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
mainelement 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?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 thanid="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
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.@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:
source: http://lists.w3.org/Archives/Public/public-html/2012Oct/0109.html
@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.
@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.
@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
@karl
new data I recently gathered on use of
role=mainand themainelement further supports the view that developers/authors working definition ofmainmatches 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 themainelement will be useful and in the majority of cases used as specified in HTML5.@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.
@Hixie
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?
According to Mr. Hickson:
“(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.”
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.
@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
mainelement, 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
@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
@Léonie Sure, most of the time you’ll only have one, like you’d only have one <footer> or one <header>.
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
@mattur,
The definition of
mainproposed 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.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.
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:
similarly
The HTML specification definition of the div element
The HTML spec definition of
main:The definition of represents
Will leave it up to others to draw their conclusions about whether I was lying…
@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
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.
The division of HTML5 in to two competing standards (and also the quarrel we just witnessed) is really really bad. Stop it!
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!
@Reinier,
Glad you see the utility of the new element :-)
Agreed and I think it would make it less likely that it is used for the primary use cases.
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.
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.
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.
@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 ;-)
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.
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.
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 ^___^
@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.
I’ll try that, Mario!
Thanks for the help!
Will Main join the http://html5doctor.com/html-5-reset-stylesheet/ :) ?
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?
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.
Is such a view to accessibility ok? That is: Use ARIA landmarks on div’s for maximum accessibility and support.
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?
Hi Tim, no
mainis for the primary content area of a page, subsections can be marked up usingarticle, for example.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!
It would be great if were added to the HTML5 Sectioning Element Flowchart (http://html5doctor.com/resources/#flowchart).
Alice, main isn’t sectioning content, so it doesn’t make sense to add it to that flowchart.
@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.
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.
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.
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.
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”) ;-)
they are already there:
footerelement that is not a descendant of an article or section element.=contentinfoheaderelement that is not a descendant of an article or section element.=bannerskip 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.
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
Hi Jakob,
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 forrole=main. All the formalization of themainelement has done is make it easier for authors to do something they were already doing.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 :)
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:
It is only necessary for newer features that have not had their accessibility support built in yet by browsers. (
mainbeing an example)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.
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.
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
mainfor my page wrapper instead of
divAs 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.
Hi Dan,
The
mainelement 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.mainis the container for the main content of the page, so in your example code you are using it as it should be used.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!
yes
@Lynda S
Alternatively, you can set explicit width/min-height on the <html> element (
html { width : 100%; min-height : 100%; /* or 100vh */ }), and give your <body> a max-width and amargin : 0 auto;to prevent needing another wrapper.@Steve Thanks for your effort with <main> and I agree that it definitely serves a stronger purpose as an entrypoint for assistive tech, and overall document outline, than as a generic container within any element.
…but, in an attempt to create reusable content (AngularJS-partials, reusable widgets, et cetera), there is still a need for an element which defines the important content in a sub-document.
In the case of a blog, where you might have a single entry per URI, having
<main>
<article class="blog-post">
<header>
<!-- title, attribution and meta-details -->
</header>
<!-- primary content -->
<aside>
<!-- related info, or tangential/behind-the-scenes details -->
</aside>
<footer>
<!-- legalese, comments, sub-nav, author-bio, etc -->
</footer>
</article>
</main>
entirely makes sense...
However, it still feels like there is a hole, squarely in the middle of that <article> where all of the real, pertinent information is contained, and the meat of that sub-document lives.
This can only be compounded if you have a desire to create several of these types of reusable skeletons, differentiated by the internal-content/layout of those structures, while using lightweight (size and selector) CSS.
<div class="stuff-the-user-actually-cares-about">
alternatively
<div class="content">
<div class="main">
<div class="primary">
are all viable...
...but this sub-document document structure is definitely the intent of <article> and <section> in the first place, and as has been stated in other places <section> is not the appropriate element here, despite there being a very logical, clear-cut (though implicit) section-header ("main/content/post-content/details/crap-you-care-about/etc").
So the question I pose to you, not as a castigation, or a request to reconsider the role of <main> (seriously, don't; it's where it should be) but more because I don't have the answers, nor the data to corroborate them, is "What could/should that element be, which happily sits, contextually as a direct child of an article/section/in-document aside , and sits as a sibling to header/footer, in the case where you wish to have several of these sub-documents, potentially in different contexts/configurations, in different widgets/components, all living together on the same page?".
I believe that code can be art, and I believe there must be something more elegant to describe this exact node, which occurs a great many times across most applications/pages I now write.
Hi there,
Nice to meet you! Just found this article really helpful. Obviously it raises some question on the best practices. Long story short I’m building a site for a online magazine. My individual article section looks something like this:
body
header
….
/header
main
article
This is where the main content of the article happens
/article
section
This is a list of archived articles a t the end of the page….
/section
/main
footer
……
/footer
/body
My question is: Should I add the /main before the section element or before the footer element?
The section of archived articles doesn’t seem to be related to the main content (unless it’s “related” articles) so I’d put it after the close of main. (and consider: is it actually nav?)
main {display:block;}
Oh. I did not see it. Now everything fell into place.
Let me ask more. Possible to put in the MAIN blocks DIV?
To construct a design where will also contain a text.
Or div framing will affect on SEO optimization?
among professionals.
xxx xxx xxx .
Bla bla bla
putting the main element inside a div is fine.
I actually have a page where I use multiple main elements in the DOM, but only one is displayed at a time.
For my use case it’s an easy way to switch between various language versions of my page: there’s a body element with two div Elements inside of it. Within each of these divs there is a header with navs, a main with sections and a footer and so on. But each of these divs is in a different language while the structure remains the same.
By default one language div is visible (with only CSS) until JavaScript selects another language and displays that div instead.
Is this really so wrong?
The article says: “Because <main> isn’t sectioning content, it doesn’t affect the document outline in the same way <article>, <nav>, or <section> do.”.
Yet every modern validator (like W3C’s validator.w3.org/nu and validator.nu) both report that it does.
E.g. if you page’s h1 lives inside the element, it will report that the body has no heading.
Either the validators are wrong, or the article is ;-)
just checked using validator.w3.org/nu and could not reproduce?
You’re correct, this doesn’t seem to be the case anymore.
I think I noticed it when the main h1 was preceded by a nav element, which creates a new section and messes up the outline.
E.g.
body
– header
– nav
– h2
– main
– h1
Will create an outline with a missing heading.
I actually submitted a proposal to both the W3C and WHATWG to remove the sectioning properties of the nav element, as it will rarely be found exclusively after the main h1 in a document.
Especially with site-wide navigation being very normal at the top of the document.
<body>
<header>
<nav><h2>Navigation</h2></nav>
</header>
<main>
<h1>Main title</h1>
</main>
</body>
Hope that’s a little clearer :)
Does elements like footer or header need to specify role atribute? The W3C Validator gives a warning message.
Warning: Element main does not need a role attribute.I’d really like to see the problem raised in this comment (and the two before) cleared up.
Many layouts use a wrapper for content+sidebar, but according to the spec it is wrong to replace that wrapper with the main element (given the sidebar content is repeated on other pages). However, I believe this is a fairly common use case.
I too love the organization of
body
– header
– main
– – content (article or section)
– – sidebar (aside)
– footer
but instead I should do something like
body
– header
– div.wrapper
– – main
– – – content (article or section)
– – sidebar (aside)
– footer
That’s just… ugly. The main element should denote the main content of a document in distinction to the main header and the main footer of that document, not in distinction to what’s inside, because then it sort of is just a redundant wrapper for article (most of the time anyways – and I do get the difference between main and article).
I know the wrapper div is mostly for styling purposes (centering or clearing floats of content and sidebars) and semantics should not (need to) address this, but still…
Maybe the main element should get a revisit like the aside, which can now peacefully act as a sidebar element?
@danilo,
i am unclear what the problem is.
If there is only one
articleorsectioncontained in themainelement, the redundacy comes from use ofsectionorarticlenot from use ofmain.There is not only just one article or section within the main element. I like to use main as a wrapper for content + sidebar, so I have this very nice document structure of:
body
– header
– main
– footer
So main isolates the main content from the header/banner and the footer/contentinfo of the document.
Inside main I use an article for a single page/post OR a section of articles for blog/archive pages.
BUT, also inside main, I like to have my sidebar(s), because, in my eyes, they are also main content in the sense that they are not header/footer nor should they be the same level as header/main/footer.
The problem now is, according to the spec I am only allowed to do it this way when the sidebar contents are unique to the page at hand – which in a WordPress scenario for example is hardly the case.
So, much like the aside element, which can now peacefully act as a sidebar element, I’d like to see the main element more freely wrapping content that is neither header/nav nor footer stuff.
And I believe I’m not alone with this.
In practice there is nothing to stop you from doing so, there are no conformance constraints on child elements of
main(it can contain any flow content. The definition is designed to discourage use ofmainas a catchall container.So this is acceptable:
body
– header
– main
— aside
– footer
Thanks. I guess I then will continue to use my nice structure of:
body
– header
– main
— article (for single page/post) OR section (for blog/archive)
— aside
– footer
Even if the aside’s content isn’t unique to the page at hand.
Understand how this rule gives the differential for use case between a div tag and a section tag; however, I am curious as to whether or no this means that there should never be an id or class selector attached to the section tag.
I would assume I am just over analyzing, since all of the examples here, and on other sites, show people using id and class selectors on their section tags. It would also make them purely for outlining and a div would then be required one level below the section in order to stylize the defined section.
I guess I am just looking for a more solid assurance that it is okay to use id and class selectors on a section tag as long as the section tag is being properly used.
Is it compulsory to use main in the structure? I mean without using main the output is same right?
P.S – I am new to HTML5 and just started to learn.
@saurabh
if you have
a header/footer on the page then use main to markup the main content area, refer to Easy content organisation with HTML5.
Danilo,
is a sidebar the main content? I don’t think so.
Use instead.
=
body
– header
– div.content
– nav
– main <—- the main information (article, list of articles etc.)
— aside
–/div.content
– footer
Yes, I think a sidebar is main content in the sense that it is neither belonging to a page’s header nor footer.
What you call the main information is already wrapped with article and I don’t want to extra-wrap it with main. In my eyes, main should wrap the content of a page (article + sidebars) in distinction to a page’s header and footer (like in a word document maybe).
Also, I think it should be possible to markup the basic structure with the new sectioning content elements, without any divs (and I know they don’t influence the document’s outline, but still…), because I think that’s what the purpose is.
If this is not possible without wrapping divs, I think there’s either an element missing or one is misdefined.
Join the discussion.