Page-Level Container Discussion for HTML5
As I started down the path of my first HTML5 web page I spent a good deal of time trying to understand the sectioning elements of HTML5 —
section — as well as the major structural elements such as
Trying to find the container to wrap the content of my page turned out to be the hardest part of the process.
Are We Talking about a
Some elements more obvious in their intended use than others, but I felt that there was no specific element to denote the main content of the page. I struggled with trying to figure out whether my content should be in an
section, or even just a
Apparently I am not alone. Even folks on the WHATWG mailing list were asking the same question. And then I saw this feedback from Hixie:
The element that contains “a website or a blog entry’s main content” is
body, as far as I can tell.
It seemed like that was the end of that. Clearly he had considered it and felt that there was no issue.
But in the past week on both the WHATWG mailing list and the W3C HTML Working Group list this topic has resurfaced. And there are some good arguments in its favor.
Why Should We Get a
One argument is that developers are already coding a solution to this, often by specifying a
div with an ID of “main” or “content.” In this scenario, the concept of paving the cowpath, where HTML5 is intended to reflect how developers actually code web pages, comes into play. If it’s already appearing in code, perhaps formalizing it can allow for consistency in structure and semantics. This is, after all, how we got
aside, and others.
Another argument centers around ARIA use for accessibility. Since elements like
footer have built in ARIA roles, developers who care about accessibility want an element with a similar built in role for the main content. Currently, these developers put
role="main" into the
div or other element that wraps their page.
The argument in favor of a
maincontent element is then a matter of demonstrating an existing pattern and an end-user benefit, in this case in the form of accessibility.
Why Shouldn’t We Get a
The flip side of this argument is that we’re just creating another element to add to the tag-soup that developers are already contending with in HTML5. Evidence today shows us that 95% of the pages that use ARIA ultimately use
role="main" properly. Those pages that use ARIA at all only make up 1.3% of a 10,000 page poll, however.
Those users who understand and want to provide accessibility are already doing it with ARIA. Adding a new element may help get more developers to accidentally support accessibility, or it may confuse the issue if its use isn’t restricted to one instance per page.
What Might This
Content Element Look Like?
Steve Faulkner proposed a new element,
maincontent, on the W3C HTML Working Group list yesterday, pointing to his own draft to start discussions. Ostensibly he concatenated the commonly used IDs of “main” and “content” that already exist in the wild when naming this element.
Where it goes from here is anybody’s guess. Discussion is happening on both lists, but with all the other activity and the push to start to wrap up the specification it may get pushed out. Perhaps this time next year there will be a solid proposal with well-formed arguments on both sides, but I wouldn’t expect to see a new element by then.
- Scooby Doo and the proposed HTML5
contentelement by Bruce Lawson.
- The discussion on the W3C HTML WG mailing list, September 2012.
- The discussion on the WHATWG mailing list, September 2012.
- HTML5 Accessibility Chops: ‘real world’ ARIA landmark use from The Paciello Group.
- New structural elements in HTML5 at Opera
maincontentelement, Unofficial Draft 9 September 2012 (not a W3C draft).
Update, November 28, 2012
main element was approved by the W3C as a First Public Working Draft, but within the first 48 hours of life has run into significant blocks. Read my write up: New
main Element Approved then Blocked.