The Truth About HTML5’s Structural Elements
What have we done so far?
- We’ve established the broad (and somewhat obscure) concept that HTML5’s structural elements are trying to improve—mostly outlining, which is currently done implicitly with heading tags.
- We’ve established what an outline is for—to help screen readers, which rely heavily on document headings.
- We’ve also touched on a better way to help blind users get around our pages with ARIA landmarks.
Let’s now look at what the HTML5 specs (both W3C and WHATWG) say about these new individual elements, starting with . . .
You need to know two things about <header>:
- It doesn’t actually do anything.
- Its intended use isn’t quite what you think it is.
The <header> element is a good example where a commonly used term has a new meaning in HTML5, while still being used to “pave the cowpaths.” You probably use <div id="header"> all the time, so calling it <header> will make it easier to read if nothing else, right? Well, here’s one of HTML5’s everyone-uses-it-so-let’s-change-the-meaning-anyway moments. Here’s what the spec says:
The header element represents a group of introductory or navigational aids.
Note: A header element is intended to usually contain the section’s heading (an h1–h6 element or an hgroup element), but this is not required. The header element can also be used to wrap a section’s table of contents, a search form, or any relevant logos.
The note is instructive—the intended purpose of <header> is to contain a section’s heading. Remember, sections are created with one of four sectioning elements (article, section, nav, aside) and generate a document outline in HTML5. The <header> element is meant to work within sectioning elements. It doesn’t create a section on its own (despite how it’s often visually represented as another sectioning element), and it doesn’t add to the document outline.
Think of <header> as something that wraps the heading of a section, which can be anything from the topmost section of a document, such as the heading inside the <body> tag (that is, the logo and all that “header” stuff we normally consider a header), right down to the header of a comment.
Really, It Doesn’t Do Anything
All the <header> element does is say “This is the header of a given section.” The trouble is, while that’s what your markup might say, at the moment none of the browsers or user agents are listening.
And according to Hickson, they probably never will be. Hickson’s openly said that these new tags are simply meant to make styling easier and shouldn’t ever impact document flow (see Hickson’s comment in “Conclusion: R.I.P. HTML5 Structural Tags” later in this chapter). So, this element doesn’t do anything now and probably won’t do anything in the future. It’s the semantic equivalent of a tree falling in a forest with no one around to hear it.
Given the <header> element doesn’t modify or add to the document outline, the actual heading you see as a bullet point in the document outline (for example, “My Great Blog”) is still set by an <h1>–<h6> element. The <header> tags just wrap those heading elements, along with any other header-y stuff, such as a date. So, you could do something like this:
<header>
<h1>My blog post</h1>
<p>Published on . . . </p>
</header>
How Can Screen Readers Use <header> When It’s Everywhere?
You may think screen readers could skip the <header> element and go straight to the content. But there’s no way we (or the user agents) can be sure the first <header> in a document is the main page header. If your markup is in a nonstandard order (the content appears first, followed by the header, footer, and sidebar), the document could have many <header>s, none of which we’d call a typical “header.” And so we’re back to square one in dealing with the “overall” header for a page.
ARIA Alternative: Banner
Fortunately for blind users, there’s an alternative. The ARIA landmark banner demarcates the “header” as we currently know it. Here’s how the ARIA spec defines the banner landmark (www.w3.org/TR/wai-aria/roles#banner):
A region that contains mostly site-oriented content, rather than page-specific content.
Site-oriented c.ically includes things such as the logo or identity of the site sponsor, and site-specific search tool. A banner usually appears at the top of the page and typically spans the full width.
It should appear only once per document so screen readers can jump straight there and be fairly sure what it is—which is exactly what we’re after.
Recommendation
The <header> element is too broad (and too pointless) to be useful. Instead, use the more specific ARIA role="banner" on the appropriate element (with a redundant “banner” class for IE6 if need be) for the traditional “header” of a page.
Here’s the spec:
The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.
Not all groups of links on a page need to be in a nav element—only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases, without a nav element.
The <nav> element does create a new section in your outline and benefits from the following:
- Being somewhat self-explanatory
- Having a seemingly useful purpose
The idea is if we mark up our navigation with the <nav> tag, blind people can bypass it and go straight to the content and then jump straight to the navigation links when they want to go somewhere else.
That’s a win for accessibility, right?
Good Intentions; Accessibility Disaster
Despite these good intentions, doing it for one minority can potentially screw up the navigation for another: IE 6, 7, and 8 users with JavaScript disabled.
Because of the way IE6–8 handles “unknown” elements, these users won’t get any CSS for this element. It could affect one in a hundred users—a higher percentage than people who use screen readers—making the whole idea of using this element somewhat moot for the short to medium term. (This is a problem for all HTML5 elements, which we’ll discuss later in this chapter.) Many modern frameworks attempt to work around this by using JavaScript to downgrade the markup to something the user’s browser can handle, but that won’t work for users with older browsers and JavaScript turned off. Since the new tags won’t work in these older browsers at all, there’s no way for them to accomplish the only thing Hickson said they’re designed for: making the page accessible.
ARIA Alternative: Navigation
Fortunately, we can use the ARIA landmark navigation instead by including role="navigation" on the appropriate <div> (or <ul>) to make our navigation more accessible without hurting accessibility for others. The ARIA spec defines the navigation landmark (www.w3.org/TR/wai-aria/roles#navigation) as follows:
A collection of navigational elements (usually links) for navigating the document or related documents.
Recommendation
Use role="navigation". Consider the <nav> element harmful until only a small number of IE8 users are left. (This effectively means Windows XP users because IE8 is the last browser they’ll get. We may be waiting a while).
<section> and <article>
These sound the same (everyone gets them confused), but they have different supposed uses. We’ll look at each one separately first and then compare the two. Please try to refrain from throwing inanimate objects or small animals while trying to get your head around them.
Here’s the spec:
The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.
Examples of sections would be chapters, the various tabbed pages in a tabbed dialog box, or the numbered sections of a thesis. A Web site’s home page could be split into sections for an introduction, news items, and contact information.
Note: Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the element.
Note: The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead. A general rule is that the section element is appropriate only if the element’s contents would be listed explicitly in the document’s outline.
Let’s try to make sense of this. The <section> element is supposed to represent a generic section in a document. So, if this chapter were a web page, we could break it up into chunks with <section> tags. It can also represent different areas of a home page, from news items to contact information. But it shouldn’t be used as a generic container element for styling—that requires a <div>.
It also shouldn’t be used for the page’s content area (and neither should <article>), but we’ll get to that in a moment when we discuss the missing <content> element.
Sections == Outlines
Again, the key to understanding <section> is understanding document outlining and the concept of sectioning a document. The spec mentions this (read the last sentence of the second note), but that’s not a lot to go on when <section> is the main workhorse for creating a document’s outline. As a rule of thumb, as far as creating an outline goes, if it’s not an <article>, <nav>, or <aside>, it’s probably a <section>.
This is also why you shouldn’t use <section> for generic containers to style. If you just throw them in so you can style an area without thinking about your outline, you’ll get an illogical, broken outline that defeats the whole point of using <section>. It’s a common mistake and shows just how poorly they’ve been explained in the spec, advocated by the experts, and understood by the community (not that I blame the community).
Russian Dolls
Don’t forget: you can nest sections (whether created by a <section>, <article>, <nav>, or <aside>). And as we saw in Chapter 3, in pure HTML5 land this determines the true heading level for an <h1>–<h6> element, not the level of the heading you use. In HTML5, the user agent (in theory) just sees them all as generic heading elements when inside a section.
So, we could use <h1>s everywhere, and the user agent would figure out whether they were nested as <h1> or <h101>. However, for screen readers (now, and probably long into the future), we’ll need to use <h1>–<h6> headings appropriately, no matter what flavor of HTML we use.
Recommendation
If you want to create outlines the HTML5 way, you’ll be mostly relying on <section>s. It took more than 20 years for the element to make it into the spec (recall Tim Berners-Lee’s comment in the previous chapter), and it will probably take another 20 years before people understand it correctly.
There’s no ARIA equivalent.
You might think an “article” is like “a newspaper article.” Well, shame on you for thinking a new HTML5 element would have an intuitive meaning. Here, it’s more like “an article of clothing.” Yep, it’s another “semantic” term with an unintuitive meaning.
Here’s the spec:
The article element represents a self-contained composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.
When article elements are nested, the inner article elements represent articles that are in principle related to the contents of the outer article. For instance, a blog entry on a site that accepts user-submitted comments could represent the comments as article elements nested within the article element for the blog entry.
And here’s Hickson on the WHATWG mailing list in early 2012 (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-January/034506.html):
<article> covers a wide range of semantics:
-forum posts
-newspaper articles
-magazine articles
-books
-blog posts
-comment on a forum post
-comment on a newspaper article
-comment on a magazine article
-comment on a blog post
-an embeddable interactive widget
-a post with a photograph on a social network
-a comment on a photograph on a social network
-a specification
-an e-mail
-a reply to an e-mail
In HTML4, a paragraph is a paragraph is a paragraph. In HTML5, an “article” is a forum post is a blog comment is a widget is an actual article. If an element has such broad meaning, how can it be more “semantic”? It’s like deciding to call knives, forks, spoons, plates, and televisions all “forks.”
This isn’t paving the cowpaths.
Again, it’s best understood in terms of outlines. The <article> element is for creating a section when you don’t want to use <section>, which is usually when you’re wrapping some chunk of content (or “interactive widget,” as the case may be).
The spec talks about how an <article> could be syndicated as a self-contained element, but how and why this would ever happen is unclear (use RSS!). It’s a solution looking for a problem.
Specifications Should Specify
The main problem with <article> is it’s open to interpretation (“What does ‘in principle’ mean? Reusable?”). Specifications fail when they leave things up to you to work out. The whole point of a specification is to specify exactly what you should do. But here it’s open to interpretation, has no clear benefit, and repeats existing functionality (it’s <section> with a different name).
Nesting <article> for Articles and Comments
You can also nest <article>s within <article>s when the content is related. The spec suggests blog comments be wrapped in <article> tags and then nested in an overall <article> for the blog entry. This is the “fork and spoon are all forks” problem. If you have <article class="post"> and <article class="comment">, then article just becomes a more verbose form of <div>.
Why not just add a <comment> element and at least have basic markup for the standard article-followed-by-comments pattern that just about every blog and publication on the Web uses? Wouldn’t that be paving the cowpaths? Not according to Ian Hickson, who injects his own idiosyncratic view on the semantics of the issue: that there is no difference between an article and a comment (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-January/034506.html):
I think it's anachronistic to consider that the utterances of the site owner are in some way distinct from the utterances of the site readers. What makes them different?
On the contrary, on the Web there _is_ no difference. An article is just a comment that has been hoisted to a more prominent position.
The irony of defining at least one of the differences between these “utterances” and then declaring there is no difference was apparently lost on Hickson.
Of course, this also flies in the face of the oft-stated goal that these elements are mostly to help authors maintain their documents. If ever there was a case where a pattern of markup has emerged—an article, followed by comments—this is it. Yet Hickson, acting as both player and referee, won’t budge, asserts his own peculiar philosophical view that all “comment” is equal, and that’s that. We’re left with nesting <article>s in HTML5, and content on the Web, it seems, will be <article>s all the way down.
Search Engines Don’t Need <article>
Some may think <article> could help search engines, but they don’t need a tag to know where your content is. Their entire existence relies on them being able to find your content without that sort of help. Even if <article> were used widely, how would they know through markup alone whether <article> meant blog post, forum post, interactive widget, comment, or whatever? It’s too broad to be useful for SEO even if they did care what tags you used (which for the most part they don’t).
(We’ll discuss this more in Chapter 6 when we look at HTML5 and SEO.)
<article> Is Not for the “Main” Part
And <article> isn’t for denoting the content area of the page. It’s worth mentioning that when Hickson dreamed up <article>, there was no main content element, and he argued vehemently against it. <main> wasn’t a thing, and <article> certainly wasn’t <main>.
Recommendation
Should you use this? I wouldn’t. Instead, I’d put it in the guilty-of-being-useless-until-proven-otherwise category. If a pragmatic benefit appears, go nuts. Until then, pass.
Like <section>, there’s no ARIA equivalent.
So, What’s the Difference Between <article> and <section>?
Here are some things you need to know:
- Articles can be nested within articles.
- Articles can be broken up by section.
- A section can be broken up into articles, which can in turn have individual sections.
- People are terrible at using markup consistently.
Guess what? Apart from the handful of markup über-nerds, anyone who actually uses these elements (and I’d be surprised if anyone does) will just create a huge mess. But hey, maybe I’m wrong.
Personally, I’d rather take a rusty potato peeler to my pinky finger than debate the virtues of <section> vs. <article>. The very fact there’s a debate at all demonstrates a failure in the spec. If you have to debate an element when implementing it, you lose.
Yet thousands of words about this fine distinction have been spilled on blog posts (for example, Bruce Lawson’s take: www.brucelawson.co.uk/2010/html5-articles-and-sections-whats-the-difference/) and comment threads.
One would have hoped the absurdity of the situation would have dawned on the community when we’re left making well-intentioned but otherwise ridiculous flow charts just to decide which HTML5 element to use (see http://html5doctor.com/downloads/h5d-sectioning-flowchart.png). Alas, it appears it has not. And all this because a WHATWG member or three decided to throw these additional <section> flavors into the Web Applications 1.0 spec in 2004.
OK, we’ve ripped off the Band-Aid and survived the most painful part of HTML5’s new elements. But there’s still some sticky residue that will sting a bit coming off, so let’s look at the last two sectioning elements.
Question: What do you call a pull quote, parenthetical information, and a sidebar?
If you said, “a pull quote, parenthetical information, and a sidebar,” you lose—buh-bow. You call them an “aside.” Obvious, huh? Here’s the spec:
The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.
The element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page.
It’s hardly obvious why a pull quote, advertising, or a blog’s navigation elements (complete with <section>s for a blog roll and archive—that’s the use cases in the spec) should be called the same thing. But in the bizarro-world of HTML5 structural semantics, they are, and you can happily ignore them.
An Aside Creates an Outline Section in Weird Places
An aside does create a section in a document outline, which makes it all the more strange given its broad use cases. (Why should a pull quote be its own section?)
If it was just for a sidebar, or even called <sidebar> (as it originally was), that might make sense, but it’s not, and it doesn’t.
ARIA Alternative: Complementary
The ARIA landmark alternative in this case is complementary, which the ARIA spec describes as (www.w3.org/TR/wai-aria/roles#complementary):
A supporting section of the document, designed to be complementary to the main content at a similar level in the DOM hierarchy, but remains meaningful when separated from the main content.
There are various types of content that would appropriately have this role. For example, in the case of a portal, this may include but not be limited to show times, current weather, related articles, or stocks to watch. The complementary role indicates that contained content is relevant to the main content. If the complementary content is completely separable main content, it may be appropriate to use a more general role.
Recommendation
Use role="complementary" on the appropriate <div> (or other element) for the sidebar in your template (and anywhere else that’s appropriate).
Remember how <header> seemed obvious but wasn’t? Well, it’s the same deal with <footer>. It sounds like it should just be the main footer, but in fact it can mean the footer for any given section. Here’s the HTML5 spec:
The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.
Contact information for the author or editor of a section belongs in an address element, possibly itself inside a footer.
Footers don't necessarily have to appear at the end of a section, though they usually do.
Footers, like headers, are something you use within a section—they don’t create a section in their own right. Again, this is confusing because in the examples in HTML5 books and blog posts the footer appears to be a distinct visual section in a template of equal importance to an <article> or <aside>, when in fact it doesn’t appear in the document outline at all. It simply describes part of the parent section, wherever (and however frequently) that section may occur.
Footer Doesn’t Do Anything Either
Like <header>, <footer> doesn’t actually do anything. In fact, <footer> doesn’t even have to go at the end of an element. The spec gives an example in the <article> section where the metadata of a comment (comment author and timestamp) is wrapped in a <footer> and placed at the—wait for it—top of the comment. Apparently the element wasn’t confusing enough.
Again, no cowpath paving here. I certainly didn’t hear a thousand web designers crying out for a <footer> element for every section on a page. Did you?
Fat Footer? Good Luck!
What if you have a trendy “fat footer” with a bunch of links and other information in it? Well, if it’s a whole chunk of content, it should be a section, so you’d use one of the sectioning elements—<nav>, <section>, or even <aside>.
But, just to keep things interesting, you can wrap that sectioning element in <footer> tags. So, <footer> can both demarcate content within a section in a document outline and wrap other sections in the document outline and yet still not create a section in its own right.
Clear as mud, huh? I don’t understand why it’s that way, and I doubt most web designers will either. I’ve seen Japanese game shows that make more sense than these elements.
Can I ’ave a Footer, Guv’na?
Proposals for a <footer> element have been around for a long time. When it was discussed in 2002—about a decade ago—in regard to XHTML 2.0 on the W3C public mailing list, people soon began criticizing it (see http://lists.w3.org/Archives/Public/www-html/2002Aug/0257.html) saying it wouldn’t provide any tangible benefit. A decade later that criticism still seems valid.
Again, as far as accessibility goes, ARIA to the rescue. Its contentinfo landmark reflects the content of traditional footers (in other words, the bit at the bottom of the page with a few links and some fine print) without a presentational name. The ARIA spec describes it as follows (www.w3.org/TR/wai-aria/roles#contentinfo):
A large perceivable region that contains information about the parent document.
Examples of information included in this region of the page are copyrights and links to privacy statements.
Unlike <footer>, it should be used only once per document.
Recommendation
We can use <div role="contentinfo"> once for the page footer. We can also keep using <div id="footer"> (or whatever you like) with role="navigation" if there’s substantial navigation elements there.
As we saw in Chapter 3, the <main> tag took some work to get added to the spec. Hickson thought it wasn’t necessary, probably because it represented the only real cowpath that anyone wanted him to pave and because it made sense to ordinary web developers. He thought you only needed to mark up things that weren’t content, and then the rest would, obviously, be content by default.
Luckily, saner heads prevailed. The W3C added <main> to its spec for HTML5.1 and then back to HTML5. Hickson begrudgingly took it into the WHATWG spec but decided he’d define it differently. That’s right: the only element that ought to be simple and self-explanatory is the one that can’t be agreed upon.
Here’s how the W3C defines <main> (www.w3.org/html/wg/drafts/html/master/grouping-content.html#the-main-element):
Themain element represents themain content of thebody 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.
Themain element is not sectioning content and has no effect on the document outline.
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).
User agents that support keyboard navigation of content are strongly encouraged to provide a method to navigate to themain element and once navigated to, ensure the next element in the focus order is the first focusable element within themain element. This will provide a simple method for keyboard users to bypass blocks of content such as navigation links.
Authors must not include more than onemain element in a document.
Authors must not include themain element as a descendant of anarticle,aside,footer,header or nav element.
Themain element is not suitable for use to identify the main content areas of sub sections of a document or application. The simplest solution is to not mark up the main content of a sub section at all, and just leave it as implicit, but an author could use a grouping content or sectioning content element as appropriate.
Authors are advised to use ARIArole="main" attribute on the main element until user agents implement the required role mapping.
That seems pretty straightforward, right? <main> represents the main content area. You can have only one. It’s not part of the outline madness, and it should be properly mapped to the ARIA role main. That seems pretty great, right?
Here’s the WHATWG definition of <main>:
The main element can be used as a container for the dominant contents of another element. It represents its children.
The main element is distinct from the section and article elements in that the main element does not contribute to the document outline.
That’s right—<main> “represents its children.” Note also everything Hickson leaves out: according to the WHATWG spec, you can have more than one <main> element (defying the semantic definition of the word main in English), you can nest “main” elements (“you’re the main of the main of the main of the main!”), and at the end of the day it doesn’t actually mean anything; it just “represents its children.”
At least the specifications do agree on two things: first, that <main> isn’t part of the outlining mess that makes the other structural elements so confusing, and second, it’s the dominant content area. That’s nice, but these differences in browser standards are starting to make HTML5 feel a lot more like the fractured controversial world of competing standards and noncompliant browsers it was supposed to save us from.
Mainly Useless Controversy
As you can see, there’s some disagreement about the way that <main> should be implemented, but the best part is none of that matters because <main> fails for the same base set of reasons the other sectional elements do: it’s not supported by older browsers, and it’s bad for accessibility.
Beyond that, Opera, Safari, and IE have all yet to implement <main> at the time of this writing. Even if accessibility or older browser support isn’t high on your list, a large portion of the Internet can’t make use of the <main> tag.
Remember that both the W3C and WHATWG always seem to agree on one central tenant for HTML5: the browser manufacturers ultimately decide what’s really real. Right now, <main> is still mostly a work of fiction.
ARIA Alternative: main
Fortunately there’s yet another ARIA landmark we can use instead, which is simply main. It does what we want it to do and serves the people we’re trying to help—blind users.
Here’s how the ARIA spec defines main (www.w3.org/TR/wai-aria/roles#main):
This marks the content that is directly related to or expands upon the central topic of the document. The main role is a non-obtrusive alternative for “skip to main content” links, where the navigation option to go to the main content (or other landmarks) is provided by the user agent through a dialog or by assistive technologies.
Recommendation
Use <div role="main"> once for the main content area of your page.
Here are a few more ARIA landmarks that may prove useful when marking up your pages:
- application for software widgets on a page
- form for forms, except search, which gets . . .
- search for the search form on the page
And they go along with the others we’ve looked at:
- banner for the overall header
- navigation for, you guessed it, navigation
- complementary for sidebars
- contentinfo for the footer
- main for the main content area
(Note that banner, main, and contentinfo should be used only once per document.)
For more about these landmarks, see Steve Faulkner’s excellent comparison to HTML5 elements: www.paciellogroup.com/blog/2010/10/using-wai-aria-landmark-roles/.
For more on ARIA in general, see Mozilla’s ARIA documentation: https://developer.mozilla.org/en/aria.
A Funny Thing Happened…Graceful Degradation Died and JavaScript Became Mandatory
In the past couple of chapters I’ve made several references to the harm these elements can inflict on another small subset of users. For some users, these tags will blow up your page in IE6, 7, or 8 with JavaScript off (which, because of personal choice and over-zealous security concerns, is more common than you may think).
The problem is how IE 6–8 handle “generic” elements. To IE6–8, a generic tag is anything it doesn’t recognize, whether it’s a completely made-up element like <mymadeuptag> or HTML5’s <nav>. Given that IE6–8 doesn’t recognize generic elements at all, we can’t style them without using a sprinkling of JavaScript to tell IE6–8 they exist.
This clever JavaScript workaround was discovered by Sjoerd Visscher and popularized by Remy Sharp in 2009 (see http://html5doctor.com/how-to-get-html5-working-in-ie-and-firefox-2/). Now that we can use a tiny bit of JavaScript to tell IE6–8 that particular elements do exist, we can happily style away . . . or can we?
No, we can’t.
But could we?
No.
(For the record, the JavaScript in question is available here: http://code.google.com/p/html5shiv/. You also need to tell other browsers to treat the new elements as block-level elements with CSS, as we touched on in Chapter 2.)
Now we hit the big snag, specifically, the IE 6–8 users with JavaScript off who don’t get the HTML5 fix.
Hang on. Does anyone actually turn JavaScript off these days? Is there any data available that could give us some insight here?
Yes, there is.
In 2010, Yahoo published the results of research it did into this very question—how many visitors do have JavaScript disabled? It turns out that 2.06 percent of visitors hitting Yahoo’s U.S. websites (which includes significant non-U.S. traffic) had JavaScript disabled, as did 1.29 percent in the United Kingdom, 1.46 percent in France, and 1.28 percent in Spain. (Brazil was an outlier with just 0.26 percent.)
So, unless you’re designing for Brazilian users, you still need to consider users who’ve disabled JavaScript.
You can read about the research at http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-have-javascript-disabled/ and about the methodology at http://developer.yahoo.com/blogs/ydn/posts/2010/10/followup-how-many-users-havejavascript-disabled/ on Yahoo’s YDN blog.
Let’s assume the high end of 2 percent for traffic to the major U.S. sites and that IE 6–8 users make up about 50 percent of your audience. That’s at least one in every hundred users with IE6–8 and JavaScript off. Even if it were one in a thousand, that’s still at least one person every day for a moderately busy site.
So, what happens to these visitors if you use HTML5 structural tags?
If you use <section> tags (or any other tags) around existing markup and don’t style them, nothing. You can still create outlines that way if you really want, as long as you remember that blind users still rely on headings to get around your page.
But if you use <header>, <footer>, <nav>, <aside>, or <article> (or <section> for that matter) where you are likely to style them, Bad Things™ happen.
Specifically, users with JavaScript disabled will see your site styled normally, except for the parts of the design that use the HTML5 elements. When those elements wrap our navigation, header(s), sidebar(s), or article(s), we have problems. The elements—unlike the rest of the page—won’t have our CSS styling applied and so may break in some pretty serious ways.
Here’s What Happens…
For example, Figure 4-1 shows the main navigation of one of my client’s sites, firstly with <div id="nav"> wrapping a normal <ul> list of links.
Figure 4-1. The site’s navigation with JavaScript disabled and no HTML5 elements
And Figure 4-2 shows it with a <nav> element instead in IE7 with JavaScript disabled.
Figure 4-2. The same navigation using HTML5’s <nav> element with JavaScript disabled
Not cool, right? And that’s just one element. Imagine if the header and sidebar broke down in similar ways, while the body, wrapper, and content areas were all still being styled. Not pretty.
What to Do? Oh, XP…
The safest thing would be to not give IE6–8 users with JavaScript disabled styles at all (which you could do with conditional statements and writing the style element with JavaScript). But I don’t advocate this—you’re still unnecessarily ruining their experience.
What about IE9 and beyond? Thankfully, IE9 recognizes most HTML5 elements and has improved how it handles generic elements.
Maybe IE9 will replace IE6, 7, and 8 sooner rather than later, and we can forget about these non-JavaScript users. Ah, what a world that would be. Unfortunately, Windows XP users will never get IE9—IE8 is the end of the road for them. As long as XP is around, we’ll have IE8 visitors whose experience is unnecessarily ruined because of these elements.
And no one should have to put up with that.
Elements such as <nav> are supposed to (theoretically) help the visually impaired. But when we do use <nav> (for example) as intended in the spec and as taught by HTML5 advocates as a replacement for existing structural markup, we unnecessarily hurt another minority in a very real way.
Uh…Web Design Community, What Happened?
One of the most unfortunate parts of the HTML5 hype in web design circles is how quickly we’ve forgotten the tradition of graceful degradation. Sure, we don’t want to be limited to the lowest common denominator. But IE8 is a long way from that, and there’s a big difference between giving those with JavaScript disabled something simpler and giving them something that’s just plain broken.
Let me make it clear I don’t have a problem if your specific web site requires JavaScript (and will break in varying ways for IE6–8 with JavaScript off); that’s the informed choice you’ve made. But I do have a problem with this issue being almost entirely ignored in the web design community and the unnecessary pain unwitting designers and developers are inflicting on a small group of users.
This issue alone sinks the usefulness of these new elements, so I recommend sticking to <div>s for structure and ARIA roles for accessibility. ARIA roles can at least help solve accessibility problems for one minority without blowing up the site for another.
Hickson himself says this (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-January/034506.html):
Naturally, if you are happy with<div class=" . . . "> for everything, you are welcome to continue doing that.
Conclusion: R.I.P. HTML5 Structural Elements
Perhaps the strangest thing about all this is I’m not sure Ian Hickson—the spec editor—is clear about what these new elements are for or what other experts think they’ll be used for.
In a conversation with Opera’s Bruce Lawson (coauthor of Introducing HTML5 [New Riders, 2010]) on the WHATWG list in 2009 (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html), Lawson said this (emphasis added):
After all, I know of no user agents that can use time, section, footer, datagrid etcbut we mostly expect there to be soon.
And here’s what Hickson said in reply:
I don’t. Most of the new elements are just meant to make styling easier, so that we don’t have to use classes.
That’s Hickson’s offhand rationale—not having to use classes—which we touched on earlier. But it’s interesting he has no expectation that user agents will do anything with them. Has he given up on sectioning and outlining? Isn’t that why these elements were added in the first place (remember they predated any research), and isn’t that how Hickson described them in the specification he edits?
These elements are a lost cause. If people do just use these elements instead of classes (which they already are), they won’t be considering the outline they’ll be creating. They may assume <header> creates a section (it doesn’t), or they may use <aside> for a pull quote (and in doing so create a new section), which will mean a lot of broken HTML5 outlines.
So, user agents (screen readers in particular) will have very little incentive to ever use HTML5 outlines—the main point of most of these elements—as a means of navigation, given they’ll be (and already are) an utter mess.
It’s sad, isn’t it? Tim Berners-Lee’s 1991 wish for sectioning finally makes it into a shipping HTML spec (after the aborted XHTML 2.0 project), only to be misunderstood and abused two decades later.
And that’s before we take into account the ambiguities in the spec, the fact they blow up styling in IE6–8, and how much they complicate marking up a basic HTML page, of all things.
Here’s John Allsopp, author of Developing with Web Standards (New Riders, 2009), commenting on the new elements on Jeffrey Zeldman’s blog (www.zeldman.com/2009/07/13/html-5-nav-ambiguityresolved/#comment-44699):
As I waded deeply through the specification, narrowing my focus largely to the new “semantic” elements like section, article, header, footer, and so on I discovered many ambiguities, poorly explained features, and baffling containment rules [as well as] near byzantine complexities.
[ . . . ]many of the legitimate criticisms of XHTML2 can also be laid at the door of HTML 5. And many others, particular to the specification itself can also be leveled. It’s time to address these.
We have the solution for marking up our pages:
- Use <div>s with classes (and/or a single id that occurs once on the page if you want).
- Use appropriate heading elements.
- Add ARIA landmarks as appropriate, and you’re done.
That’s how easy it is to describe structural markup now.
That simplicity has been lost in HTML5.
That’s the bad news. The good news is, all is not lost. We can take this opportunity to try using headings in a better structural way to make blind and sight-impaired users’ lives a bit easier (and start using ARIA landmarks for the same reason). And we can be happy knowing that our existing HTML structural markup techniques will serve us just fine for many years to come.
Let me finish by saying that despite my criticism of this particular part of the HTML5 spec (and the web design community’s advocacy for it), if it weren’t for Ian Hickson and the WHATWG, there wouldn’t be an “HTML5” as we know it today—we could still be waiting for the W3C to get its act together. It’s not my aim to bite the hand that feeds . . . just nibble on its fingers a little bit.
Next, let’s talk about the S word: semantics.