Page-Level Container Discussion for HTML5

This post originally appeared on my blog.

HTML5 logo — I am the 'alt,' not the 'title' 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 — nav, article, aside, and section — as well as the major structural elements such as header and footer.

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

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 article, a section, or even just a div.

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

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 nav, aside, and others.

Another argument centers around ARIA use for accessibility. Since elements like header and 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 content / main / 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 Content Element?

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.

Related

Advertisements

2 thoughts on “Page-Level Container Discussion for HTML5

  1. Yes, we already use the heck outta #main and such constructs… and I think that’s adequate.

    Why?

    We already have header, footer, article, and section and aside elements, and those are good for describing hierarchy. We have body to describe what usually ought to be user-readable.

    …But when we use #main, what are we using it for? In my experience, it’s always used as a CSS hook, to compose content relative to the page canvas.

    If we’re going to supplant #main, we ought to do it with CSS, not HTML. Table-style layout properties give us an obvious option, or a property could be introduced that creates virtual Fibonacci squares and allows the stylist and designer to anchor elements to a given intersection of that construct, or… you get the idea.

    Creating an element that simply allows us to write something like content { width: 994px; margin: auto; } instead of #main { /* ditto */ } seems almost silly. That silliness takes on yet more character when you consider that we WANT that composition rule to have some priority.

    • It’s less about the CSS hook and more about an ARIA hook. Right now ARIA roles come implicitly with aside, header, nav, footer, etc. Developers don’t need to do anything other than use those elements to make them accessible via ARIA. However, there is an ARIA role for “main content of a page” that is not a part of any native main content element, which means developers must know about ARIA and remember to put role=”main” on the parent-most content element to make it accessible. Given how few sites use ARIA roles now there is an argument to create an element which itself becomes that ARIA role.

      I am flipping back and forth on this myself Leaning on the body element to take that role ends up capturing everything on the page, and so doesn’t really provide useful context for a user. Making a new element is just more tag soup and potential for mis-use.

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s