The Definition #

The <output> element, new in HTML5, is used in forms. The WHATWG HTML specification describes <output> very simply:

The output element represents the result of a calculation.

Along with the standard global attributes, <output> also accepts the following:

for

A space-separated list containing the IDs of the elements whose values went into the calculation.

form

Associates the <output> element with its form owner. The value must be the ID of a form in the same document. This allows you to place an <output> element outside of the <form> with which it is associated.

name

The name of the element.

Implementing <output> #

We’ll start by creating a simple example that adds two whole numbers together (Figure 1). We’ll use the new-in-HTML5 number input type and the parseInt JavaScript function to convert the input strings to integers:

<form onsubmit="return false" oninput="o.value = parseInt(a.value) + parseInt(b.value)">
  <input name="a" type="number" step="any"> +
  <input name="b" type="number" step="any"> =
  <output name="o"></output>
</form>

See a live example of the code in Figure 1.

As you’d expect, if you only enter a single value, the function returns NaN. It’s effectively trying to add a number and an undefined value, and 1 + undefined = undefined.

<form onsubmit="return false" oninput="o.value = parseInt(a.value) + parseInt(b.value)">
  <input name="a" id="a" type="number" step="any"> +
  <input name="b" id="b" type="number" step="any"> =
  <output name="o" for="a b"></output>
</form>

<form onsubmit="return false" oninput="o.value = a.valueAsNumber + b.valueAsNumber">
  <input name="a" id="a" type="number" step="any"> +
  <input name="b" id="b" type="number" step="any"> =
  <output name="o" for="a b"></output>
</form>

Invoicing Calculator: An In-depth Example with Fallbacks #

For a more realistic example, let’s create an invoicing calculator that multiplies the number of hours by the hourly rate and adds tax to give an overall total (Figure 4):

<form onsubmit="return false" oninput="amount.value = (hours.valueAsNumber * rate.valueAsNumber) + ((hours.valueAsNumber * rate.valueAsNumber) * vat.valueAsNumber)">
  <legend>Invoice</legend>

  <p><label for="hours">Number of hours</label>
  <input type="number" min="0" id="hours" name="hours"></p>

  <p><label for="rate">Rate</label>
  <span>£</span><input type="number" min="0" id="rate" name="rate"></p>

  <p><label for="vat">VAT</label>
  <input type="number" min="0" id="vat" value="0.20" name="vat"></p>

  <p>Total: <strong>£<output name="amount" for="hours rate vat">0</output></strong></p>
</form>

See a live example of the code in Figure 4.

Nothing too complicated going on there. In fact, the scripting is so simple that even I can do it

A Mildly Controversial Example Using <input type="range"> #

HTML5 also introduces the range input type, which renders as a slider control in supporting browsers. With this input type, a user can enter an approximate value within a given range without having to be completely precise or directly type a numeric value. For cross browser compatibility, see Remy’s input range polyfill.

While researching this article, I found a number of examples using the <output> element in conjunction with <input type="range"> as shown in Figure 5:

<form onsubmit="return false" oninput="level.value = flevel.valueAsNumber">
  <label for="flying">Flying Skill Level</label>
  <input name="flevel" id="flying" type="range" min="0" max="100" value="0"> 
  <output for="flying" name="level">0</output>/100
</form>

See a live example of the code in Figure 5.

Using <output> to show the current value to the user seems like a perfectly reasonable use case to me, but it isn’t the result of a calculation as the spec describes. I haven’t spoken directly to Hixie about this, but a couple of people on the IRC channel seemed to agree with, so I filed a bug report to request the definition be amended. I’ll update this article if something changes.

Browser Support and Polyfills #

The good news is that all modern browsers support the <output> element to some extent. The bad news is that there are still a few gotchas.

* Firefox does support the <output> element and the oninput event, but it doesn’t support the valueAsNumber property.

All the examples we’ve seen so far should work perfectly in Opera 11.5+, Safari 5.1+, and Chrome 13+. IE, as you might expect, is lagging somewhat, but support for <output> is in IE10 Platform Preview 2, and support for oninput is already in IE9.

In order to work around this in our simple examples, we’ll need to revert to the tried-and-trusted getElementByID and parseFloat (Figure 6):

<form onsubmit="return false" oninput="document.getElementById('o').innerHTML = parseFloat(document.getElementById('a').value) + parseFloat(document.getElementById('b').value)">
  <input name="a" id="a" type="number" step="any"> +
  <input name="b" id="b" type="number" step="any"> =
  <output name="o" id="o" for="a b"></output>
</form>

See a live example of the code in Figure 6.

While this isn’t ideal, it’s workable until those less-capable browsers die a slow and painful death. Alternatively, you can use polyfills to plug the gaps.

To check support in your current browser, open up Mike Taylor’s support test page.

Summary #

You probably won’t find yourself using the <output> element all the time, but it’s useful in a whole host of situations. Calculating values on financial sites spring to mind, or outputting the current mouse position, or perhaps the goal difference in a table of sports teams. What other use cases can you think of for <output>? Let us know in the comments!

Related reading #

• WHATWG HTML Specification for <output>
• W3C Elements Wiki Page for <output>
• Wufoo HTML5 Forms Tests for <output>
• Mozilla Developer Network docs on <output>
• Is onforminput Deprecated in HTML5 Forms? (And Why Should I Care Anyways?) by Zoltan Hawryluk
• A HTML5 Browser Maze: oninput Support by Daniel Friessen
• Fixing oninput in IE Using html5Widgets by Zoltan Hawryluk

Overview

Personally, I’ve never been keen on video-based learning like this. As such, I wasn’t sure what I’d make of HTML5 Now. It turns out I was pleasantly surprised by the format, the content, and the presentation.

Tantek has an natural, engaging presentation style, and his knowledge of the subject area ranks up there with the best of them. He begins with an interesting historical look at HTML and in turn how HTML5 came to be. This section is full of things you might not know about HTML, let alone HTML5.

A few other thoughts:

• Tantek constantly urges you to get involved and share your experiences.
• The early parts of the DVD contain in-depth background information on elements and attributes.
• Tantek presents a clear, concise introduction to <ruby> and friends, even explaining how it’s worked in IE for 10+ years!
• He introduces his bulletproof HTML5 syntax (using <div>s with class names inside new elements).
• The accompanying booklet effectively takes notes for you so you don’t have to. Just sit back and enjoy!
• The DVD also contains the slides shown throughout the presentation and a PDF of the booklet.
• A few tongue-tied moments help keep it real, not staged or forced. It shows Tantek really cares about the subject.
• You’ll get some good tips on when to use the new elements. Additionally, some elements are more stable since the DVD was released.
• Each section is concluded by a brief summary recapping what you’ve learnt.

Words of warning

As is the case with any book or DVD based on the constantly evolving HTML5 specification, parts of the DVD are now out of date. (It was originally released in July 2010.) Look out for these gotchas:

• Certain sections don’t mention browser support.
• <u> is now a part of the HTML5 specification.
• The WebM video codec didn’t exist at the time of production.
• There is no mention of form attributes and support for the new input types.
• <canvas> is incorrectly described as a vector format (it’s bitmap).
• It’s a shame that Tantek only scratches the surface of <video>, <audio>, <canvas>, and SVG. They each deserve their own DVD!

Summary

I’m still not convinced that DVD is the best format for this type of content. As with print, it goes out of date very quickly. Alternatively, you could simply publish the video(s) on a website and make them available on a subscription basis. That way, outdated information could be updated more regularly. That’s a discussion for another day, though, and I’m sure Tantek would be keen to see it happen.

In my opinion, the DVD is better suited to someone who has some prior knowledge of HTML and HTML5. It’s certainly not for beginners, but it does come recommended. You’ll definitely learn something. I’ll leave you with a video of Tantek (Figure 2) discussing the state of HTML5 at the Voices that Matter Conference just before the DVD was released:

Name-value pairs in HTML

Eric asked:

I work on a lot of HR applications where we need to present data on employees. I’ve never been entirely clear on the best way to mark this up. For example:

Name: John Smith
Organization Code: 12345
Date of Birth: 1/1/1900

I’ve been tempted to use <dl>‘s setting the “key” in a <dt> and the “value” inside the <dd>. For example:

<dl>
  <dt>Name:</dt>
  <dd>John Smith</dd>
</dl>

but I’m pretty sure that doesn’t mesh well with the actual intended use of the definition list. I feel like there ought to be someway to semantically relate the key to the value. Simply using just a span + class value doesn’t seem ideal. Suggestions?

In HTML5, the specification of <dl> has been widened so that it’s now an association list:

The dl element represents an association list consisting of zero or more name-value groups (a description list). Each group must consist of one or more names (dt elements) followed by one or more values (dd elements). Within a single dl element, there should not be more than one dt element for each name.

Name-value groups may be terms and definitions, metadata topics and values, questions and answers, or any other groups of name-value data.

You can read more in our article on the <dl> element.

So you can use a <dl> there, but I’d probably use a <table>. And I’d definitely use the <time> element for the DOB.

Cheers, Bruce.

E-commerce

Tom asked:

I’ve read “Introducing HTML 5″ and a fair few articles on the web, yet I have yet to come across anything that explains how to best take advantage of HTML 5 when displaying items in a shop category? It seems the new elements are designed for feeds such as blog posts or news.

Let me answer your question with another question: Could you not, hypothetically, list shop products in a feed? Wouldn’t this make them similar to blog posts? In fact, they are very similar semantically as standalone entries within a larger system. From this, you can deduce that a shop product could be marked up in the same manner as a blog entry, or forum post, or feed item. In that case, <article> will commonly be an appropriate choice to wrap up your product.

An <article> is a self-contained discrete item. So a product could be wrapped in an <article> element (assuming that’s what you mean by “shop category”). There’s considerable discussion of that in our first Simplequiz.

To fully understand what HTML5 is trying to achieve, you have to think a little abstractly. But once you get used to that way of thinking, picking the right elements will be a breeze! Have a look at our Sectioning Element flowchart for more info.

Thanks, Mike.

Lightboxes and modal windows

James asked:

What do you think the proper markup for lightboxes and modal dialog boxes (collectively, “popups”) would be? It’s important that the element be able to contain a <header> and <footer>. I don’t like <aside> or <figure> because the popup isn’t ancillary to the content; rather, it replaces or supplants the focus. I would opt for a <section>, but your flowchart indicates that they should have headings, which not all popups will. I’d love to hear your thoughts.

IMO the actual element depends on the contents. <figure> might be appropriate, as might <details> or <form> for a login form, and <aside> could also work. <section> doesn’t always need a heading, just usually.

There was a bug filed to adopt a modal attribute — e.g., <section modal> — which would automatically make this happen. Also see showModalDialog().

I know that Hixie wants this, but it’s probably for HTMLnext rather than HTML5: there’s enough to implement already! In an interview I did with him last year, I asked:

Bruce: What’s your fave feature that didn’t get into HTML 5 that you’d put into HTML 6?

Hixie: In-window modal dialogs or dialog box — the kind of prompt you get when the computer asks you a question and won’t let you do anything else until you answer the question. For instance, the window that comes up when you say “Save As…” is usually a modal dialog. Right now people fake it with divs and complicated styles and script. It would be neat to just be able to say “make this section a modal dialog”. Like showModalDialog(), but within the page instead of opening a new window with a new page. I’d add it to HTML 5, but there are so many new features already that we need to wait for the browsers to catch up.

Full interview available at webstandards.org.

Thanks, Bruce

Why do we need these new elements?

James asked:

Doctor, doctor!

I, like many, get very excited over all of the new ‘features’ that HTML5 brings including Video and Canvas.

What I can’t get my head around, is all of these new elements? I understand why <footer> <nav> <header> <section> have been introduced — to match what would typically common uses for divs, but I’m interested in knowing what usefulness this brings and when we will see the ‘positive results’ of the use of these new elements.

For example, when screen-scraping a page I can imagine a screenreader would find it useful to be able to identify, through element name, what part of the page is being read… is this the sole reason for these new elements (not saying that’s a bad thing!) and are any screen readers out there making use of this already that we can see? Are there other advantages?

Many thanks, James

Like you said, a screenreader is one beneficiary of the new elements, but a screenreader, at its core, is just a machine. Other machines can also take advantage of what HTML5 has to offer, from search engines to feed readers. While implementations are sparse at the moment, it’s up to people like you, me, my fellow doctors, and every other person taking an interest in HTML5 to do cool things with these new additions.

So when will see “positive results”? When we all pull our fingers out and get cracking! Spread the word

Regards, Mike

Optional subtitle

Björn asked:

Hi doc,

Is it ok to have an empty h2 tag or does it always have to contain text? I ask this question because some of my pages use a subtitle (h2) and others don’t need a subtitle.

If not allowed, this would have weird consequences: the semantic meaning of an h3 tag on a page with an h2 subtitle atop would have the same hierarchical and semantic meaning as a h2 tag on a page without a subtitle, not to mention the CSS styling complications this would bring.

I’d say you shouldn’t have an empty <h2> (with a few obscure exceptions, like a placeholder that’ll be filled by JavaScript), but it’s no problem because there’s a new HTML5 element that’ll solve your dilemma — <hgroup>. You can read a detailed write up in our <hgroup> article, but in essence, when you’ve got a title and a subtitle next to each other, wrapping them with <hgroup> prevents the subtitle from getting in the document outline:

<article>
  <hgroup>
    <h1>Title</h1>
    <h2>Subtitle</h2>
  </hgroup>
  <p>...</p>
  <section>
    <h2>Section title</h2>
    <p>...</p>
  </section>
</article>

It also means you can style the subtitle <h2> differently from following <h2> elements, for example:

h2 {font-size: 1.75em;}
hgroup h2 {font-size: 1.125em;}

Finally, if you’re using HTML5′s sectioning elements (<article>, <section>, <nav>, <aside>) and making sure that each title has a corresponding sectioning element wrapper (with the exception of subtitles inside <hgroup>), then you can use whatever heading levels you like and you’ll still get the correct hierarchical outline. It’s still best to make (and stick to) a logical visual hierarchy, from most to least important.

peace – Oli

Got a question for us?

That wraps up this round of questions. If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.

Don’t use section as a wrapper for styling

One of the most common problems I see in people’s markup is the arbitrary replacement of <div>s with HTML5 sectioning elements — specifically, replacing wrapper <div>s (used for styling) with <section>s. In XHTML or HTML4, I would see something like this:

<!-- HTML 4-style code -->
<div id="wrapper">
  <div id="header">  
    <h1>My super duper page</h1>
    <!-- Header content -->
  </div>
  <div id="main">
    <!-- Page content -->
  </div>
  <div id="secondary">
    <!-- Secondary content -->
  </div>
  <div id="footer">
    <!-- Footer content -->
  </div>
</div>

Now, I’m instead seeing this:

<!-- Don’t copy this code! It’s wrong! -->
<section id="wrapper">
  <header>  
    <h1>My super duper page</h1>
    <!-- Header content -->
  </header>
  <section id="main">
    <!-- Page content -->
  </section>
  <section id="secondary">
    <!-- Secondary content -->
  </section>
  <footer>
    <!-- Footer content -->
  </footer>
</section>

Frankly, that’s just wrong: <section> is not a wrapper. The <section> element denotes a semantic section of your content to help construct a document outline. It should contain a heading. If you’re looking for a page wrapper element (for any flavour of HTML or XHTML), consider applying styles directly to the <body> element as described by Kroc Camen. If you still need an additional element for styling, use a <div>. As Dr Mike explains, div isn’t dead, and if there’s nothing else more appropriate, it’s probably where you really want to apply your CSS.

With that in mind, here’s the correct way to mark up the above example using HTML5 and a couple of ARIA roles. (Note: you may need one <div> depending on your design.)

<body>
  <header>  
    <h1>My super duper page</h1>
    <!-- Header content -->
  </header>
  <div role="main">
    <!-- Page content -->
  </div>
  <aside role="complementary">
    <!-- Secondary content -->
  </aside>
  <footer>
    <!-- Footer content -->
  </footer>
</body>

If you’re not quite sure which element to use, then I suggest you refer to our HTML5 sectioning content element flowchart to guide you along your way.

Only use header and hgroup when they’re required

There’s no sense writing markup when you don’t have to, right? Unfortunately, I often see <header> and <hgroup> being used when there’s no need for them. You can get up to speed with our articles on the <header> element and the <hgroup> element, but I’ll briefly summarise:

• The <header> element represents a group of introductory or navigational aids and usually contains the section’s heading
• The <hgroup> element groups a set of <h1>—<h6> elements representing a section’s heading when the heading has multiple levels, such as subheadings, alternative titles, or taglines

<!-- Don’t copy this code! No need for header here -->
<article>
  <header>  
    <h1>My best blog post</h1>
  </header>
  <!-- Article content -->
</article>

<article>  
  <h1>My best blog post</h1>
  <!-- Article content -->
</article>

<!-- Don’t copy this code! No need for hgroup here -->
<header>
  <hgroup>  
    <h1>My best blog post</h1>
  </hgroup>
  <p>by Rich Clark</p>
</header>

<header>
  <h1>My best blog post</h1>
  <p>by Rich Clark</p>
</header>

<!-- Don’t copy this code! No need for header here -->
<header>
  <hgroup>  
    <h1>My company</h1>
    <h2>Established 1893</h2>
  </hgroup>
</header>

<hgroup>  
  <h1>My company</h1>
  <h2>Established 1893</h2>
</hgroup>

Don’t wrap all lists of links in <nav>

With 30 new elements (at the time of writing) introduced in HTML5, we’re somewhat spoilt for choice when it comes to creating meaningful, structured markup. That said, we shouldn’t abuse the super-semantic elements now made available to us. Unfortunately, that’s what I see happening with <nav>. The spec describes <nav> as follows:

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.

Note: Not all groups of links on a page need to be in a nav element — the element is primarily intended for sections that consist of major navigation blocks. 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; while a nav element can be used in such cases, it is usually unnecessary.

The key phrase is ‘major’ navigation. We could debate all day about the definition of ‘major’, but to me it means:

• Primary navigation
• Site search
• Secondary navigation (arguably)
• In-page navigation (within a long article, for example)

While there isn’t any right or wrong here, a straw poll coupled with my own interpretation tells me that the following shouldn’t be enclosed by <nav>:

• Pagination controls
• Social links (although there may be exceptions where social links are the major navigation, in sites like About me or Flavours, for example)
• Tags on a blog post
• Categories on a blog post
• Tertiary navigation
• Fat footers

If you’re unsure whether to mark up a list of links with <nav>, ask yourself this: Is this major navigation? To help answer the question, consider the following rules of thumb:

• Don’t use <nav> unless you think <section> would also be appropriate, with an <hx> — Hixie on IRC
• Would you add a link to it in a ‘skip to’ block for accessibility?

If the answer to these questions is ‘no’, then it’s probably not a <nav>.

Common mistakes with the figure element

Ah, <figure>. The appropriate use of this element, along with its partner-in-crime <figcaption>, is quite difficult to master. Let’s look at a few common problems I see with <figure>.

<!-- Don’t copy this code! It’s wrong! -->
<header>
  <h1>
    <figure>
      <img src="/img/mylogo.png" alt="My company" class="hide" />
    </figure>
    My company name
  </h1>
</header>

<!-- Don’t copy this code! It’s wrong! -->
<header>  
  <figure>
    <img src="/img/mylogo.png" alt="My company" />
  </figure>
</header>

<header>  
  <h1>My company name</h1>
  <!-- More stuff in here -->
</header>

Don’t include unnecessary type attributes

This is probably the most common problem we see in HTML5 Gallery submissions. While it isn’t really a mistake, I believe it’s best practice to avoid this pattern.

In HTML5, there’s no need to include the type attribute on <script> and <style> elements. While these can be a pain to remove if they’re automatically added by your CMS, there’s really no reason to include them if you’re coding by hand or if you have tight control over your templates. Since all browsers expect scripts to be JavaScript and styles to be CSS, you don’t need this:

<!-- Don’t copy this code! It’s attribute overload! -->
<link type="text/css" rel="stylesheet" href="css/styles.css" />
<script type="text/javascript" src="js/scripts.js"></script>

Instead, you can simply write:

<link rel="stylesheet" href="css/styles.css" />
<script src="js/scripts.js"></script>

You can also reduce the amount of code you write to specify your character set, amongst other things. Mark Pilgrim’s chapter on semantics in Dive into HTML5 explains all.

Incorrect use of form attributes

You may be aware that HTML5 has introduced a range of new attributes for forms. We’ll cover them in more detail in the coming months, but in the meantime, I’ll quickly show you a few things not to do.

<!-- Don’t copy this code! It’s wrong! -->
<input type="email" name="email" required="true" />
<!-- Another bad example -->
<input type="email" name="email" required="1" />

<!-- Don’t copy this code! It’s wrong! -->
<input type="email" name="email" required="false" />

<input type="email" name="email" required />

Summary

It would be impossible for me to list here all the quirky markup patterns and practices I’ve come across, but these are some of the most frequently seen. What other common markup mistakes have you spotted around the web? Which areas of HTML5 require further clarification? We’d love to help get the wording or examples in the spec changed to make them a little more specific, so leave your thoughts below, and don’t forget to escape your HTML!

HTML5 syntax dilemma

Manuel asked:

In theory, HTML5 syntax is very lazy but, in fact, when you write a HTML5 page you follow some conventions that originate in the XHTML era: lowercase code, double-quoted attribute values, properly closed elements, proper element nesting. While this practice is rational and admirable, some people take a further step towards a XHTML-style syntax: they don’t use attribute minimization and do terminate empty elements. Of course this further step is not necessary to write clear HTML5 code, but could be fostered if you look at the following points:

1. it makes [it] easier to upgrade legacy XHTML code (which represents the bulk of the web even if it’s generally served as text-html) to HTML5 (it’s just a matter of doctype change)
2. it makes [an] easier the shift to HTML5 for web developers, since they are generally used to write XHTML
3. it could set a coding standard in the field

What do you think about it?

I disagree. I think there’s nothing lazy about HTML5 syntax. You could say that it’s lazy that in HTML we write <hr> rather than <horzontalrule>, but the fact is, it’s a specified part of the language.

Furthermore, “legacy XHTML” code does not represent the bulk of the Web; 61% of the Web is HTML4 according to the Opera MAMA study in 2008.

But it doesn’t matter. You say tom-ay-toes, I say to-mah-toes; you like XHTML syntax, I like HTML syntax. They’re all the same to a browser, if served as text/html.

Cheers, Bruce

Sections within sections

Corey asked:

Don’t know if this has been asked before or not, as I couldn’t find anything to tell me otherwise. I read through the article and section information and understand more or less how they function, but I’m wondering if there is a case to be made about having a section within a section. Your article doesn’t really touch on whether this is appropriate or not.

The reason I ask is because I have a page that is broken into different parts (introduction, description, requirements, etc) that are all part of the same overall article. Now if I wanted to break down say, the requirements section into sub-sections (technical, stylistic, semantic, etc) would it be all right to wrap those sub sections in a section tag (that is within a section itself), assuming I put the correct header on it?

Thanks a bunch,

Yes, you certainly can nest <section>s — in fact, that’s pretty much exactly what <section> is for! If you look at the source of some of our more recent articles — e.g., this article or our microformats article — you’ll notice how we’ve split the article into sections.

In theory, using nested sections means that we’ll be able to do away with <h2>–<h6>, since a new heading level is implied with each nested section. In practice, however, it’s not as simple as that, so we suggest sticking with the usual <h1>–<h6> heading structure even if you decide to nest sections.

For your example, this code would be entirely appropriate:

<article>
  <h1>Article name</h1>
  <p>...</p>
  <section>
    <h2>Introduction</h2>
    <p>...</p>
  </section>
  <section>
    <h2>Description</h2>
    <p>...</p>
      <section>
        <h3>Technical</h3>
        <p>...</p>
      </section>
      <section>
        <h3>Stylistic</h3>
        <p>...</p>
      </section>
  </section>
  <section>
    <h2>Requirements</h2>
    <p>...</p>
  </section>
</article>

Each part of the <article> is wrapped in a <section>. The one exception might be the introduction, unless you are explicitly declaring a heading with it. You don’t always need a <header> element if it would only contain a single <h1>–<h6> element. In that case, the heading on it’s own will be fine. Bruce has a good post on the difference between articles and sections.

Hope that helps, Rich

Since we’re being semantic…

Rob asked:

HTML5 is working towards being more semantic, but I don’t think the <link/> tag is semantic at all…especially for stylesheets! Has anyone ever suggested changing the specification for the <style> tag to have an ‘src’ attribute that would point to the CSS file? Current:

<link rel="stylesheet" href="style.css" />

Suggestion:

<style src="style.css"></style>

I think most implementors would say that the current way works well enough. Breaking backwards compatibility for the sake of theoretical purity was where XHTML 2 was heading before it was finally curtailed. HTML5 takes stock of where we are, warts and all, and builds on that. (I feel your pain: I always want <img> to be <image>.)

Cheers, Bruce

Describing the content of <figure>

Sverri asked:

A lot of things can be presented as figures (everything from a simple quote to an information-dense canvas). The first thing that came to my mind was using e.g. a “type” attribute. For example:

<figure type="code css">
  <figcaption>Styling p tags</figcaption>
  <code>p { margin-bottom: 1em }</code>
</figure>

That would be a dead simple way of succinctly telling user agents, search engines, etc. what kind of content they can expect to find in the figure. However, since this is not valid HTML5 (as far as I know) how would you recommend describing the contents of a figure, so as to make it more accessible to non-human agents?

Thank you.

Bruce replied:

What would be the purpose of doing so? For example, it’s easy for a non-human agent to see that your example contains code, or that:

<figure>
  <video>...</video>
  <figcaption>...</figcaption>
</figure>

contains video, or that:

<figure>
  <img />
  <figcaption>...</figcaption>
</figure>

contains an image. So I’m not sure of the use case for a type attribute.

Sverri then responded:

The way I think about this is that figures are images of sorts, or embedded content. A “type” attribute (or perhaps a more aptly named “of” attribute) would be the equivalent of the “alt” attribute of img. It is extra information, and as such would not always be needed, but sometimes it can be an important part in how you present the content.

As for use cases:

• Aiding search engines better understand the content
• Browsers can use such information to make browsing the internet richer

I realize that you can use some other way of describing the content, such as titles, itemscopes or other ways of adding metadata. A dedicated, but optional, attribute for this would not be such a bad idea in my opinion.

To sum up, I suppose what I am getting at is that content in a figure is not always so well defined on its own. A snippet of code, for example, is given more meaning if it is in a context, such as “css”, “algorithm” or “while loop”.

I hope I am being clear enough in what I am saying.

Bruce followed up once more:

You are clear. There have been many such discussions during the development of HTML5 (and preceding versions of HTML). For example, why not have a <name> element for marking up people’s names, analogous to <time>? Why not have <geo> or <place> or <location>?

The use cases you describe (aiding search engines and browsers) are equally applicable.

But it comes down to two factors:

First, HTML is not a specialised language. It’s a generalised language, and there are some cases that can’t be marked up with the existing crop of elements. (There are already over a hundred.)

Second is that minting new elements and attributes isn’t “free”. It’s more for authors to remember (and get wrong), it bloats parsers in browsers, and it makes regression testing harder. So if a new addition to the language doesn’t solve a very common problem, it isn’t added to the language.

As you said, microdata/microformats/RDFa can be used to extend the language for specialised cases.

Thanks, Bruce

Web app buttons and toolbars: anchors, buttons, or commands?

Christian asked:

If you’re creating a toolbar for a web app, or perhaps even a “Share this page” widget, should one use anchors, buttons or commands?

A toolbar should be HTML5 <menu> with nested <command>s, but browser support is zilch. I’d use a list of buttons, personally. I think <button> is the right element to perform tasks that might need an “undo”, like “Tweet This” or “Delete Document”.

Bruce

Got a question for us?

That wraps up this round of questions. If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.

Separation of formatting and content

Graham asked:

When I first started learning html and CSS I was constantly told not to use b or i tags as the idea was to completely separate formatting from content. Is this now not the case?

In HTML 4 (and XHTML 1.x), the elements <b> and <i> (plus some others) were presentational — they only had visual meaning. This doesn’t work so well for blind users, for example.

In HTML5, presentational elements have either been cut or, as in the case of <b> and <i>, given semantic meanings to make them media-independent. You can find out more here: The <i>, <b>, <em>, and <strong> elements and The <small> and <hr> elements.

So to directly answer your question, in HTML5, <b> and <i> are now content (semantic), not formatting (presentational).

peace – Oli

Custom elements

Eric asked:

It is possible to use custom elements in HTML5 to be more semantic; however, is it ill-advised? For example:

<footer id="page-footer">
<copyright>Copyright ©...</copyright>
</footer>

Umm, no, HTML5 doesn’t allow “custom elements”. While browsers will try to recover gracefully if you do this, making stuff up is definitely ill-advised — something like <copyright> will have no meaning for browsers and could lead to problems in IE.

If you want an element for a copyright statement or other short legalese, there’s already a perfectly good one in <small>.

If you can’t find a more semantically appropriate element, use <span> for phrasing (inline) content, <p> for a block of phrasing content, or <div> for flow (block-level) content, and add a class name that indicates the semantics — e.g. <span class="lorem">Lorem ipsum</span>.

Hope that helps!

peace – Oli

Marking up social links

A reader asked:

Could a list of share icons (twitter, facebook, etc) be considered a candidate for use of the nav element? and do links in a nav element have to be into the same domain name”?

<nav> is for navigation around your content. On my personal site, I have a link to my Flickr photostream marked up in the same container as links to my own contact page, etc. I think the link to Flickr is conceptually no different to navigation within my personal site: it’s all my content. If my photos were on my own domain (as they used to be), I wouldn’t hesitate to include them in <nav>, and I wouldn’t hesitate to include this same content within <nav> today.

A list of share icons isn’t <nav> for two separate reasons.

First, they aren’t meant to take you somewhere else. They’re designed to perform an action of tweeting/”liking” a link to a page.

Second, and most importantly, they’re not navigation around your content. As the spec says “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.”

As a list of share icons is tangential to your content, I’d probably use the <aside> element: “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”. For more details, check out our <aside> revisited article.

Social links are the kind of thing that could be cut from a feed reader without diminishing the value of the content. As an additional note, remember that you can also place an <aside> at the end of an article, like a footer. In spite of its name, <aside> doesn’t have to be a sidebar.

Thanks, Bruce and Mike

Sections with no visible titles

Francesco asked:

I have some divs, in a page, that semantically would make more sense as sections as there are natural headings for them, but they’re not written *inside* them, they’re outside. There are tabs to switch the visibility of these sections, and the tab navigation is on their left… so the actual title is only there, and not repeated inside of the sections. But besides that they really are sections… they even had “class=section” in the old version.

What would the best solution be? Put an h1 in there with display:none? It would make the outline correct, but it looks like a hack.

You should reorganise your markup to ensure the headings are within the section. Then you can use some CSS positioning trickery to move them into place. Don’t use display:none, though, as that’s invisible to everyone, including assistive technologies like screen readers.

Cheers, Rich

HTML5 <canvas> and the DOM

Elango asked:

Is it possible to get the elements i have drawn into the canvas using some API. Say for eg i draw 2 circle and 2 lines is that possible for me to get these information from Canvas by using DOM API’s

No. Think of a canvas like a canvas you would physically paint on. If you paint a red stroke and then paint over that in blue, you can’t get back to the original red stroke. The canvas API works the same way: once your pixels are committed, you can’t go back.

You want SVG (or try out Raphaël).

Cheers, Remy

Got a question for us?

That wraps up this round of questions. If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.

Wikipedia Infoboxes

Andrés asked:

Hello. I want to ask how I can code some stuff based on Wikipedia infoboxes with HTML5, which most of the time uses tables. I think that all of these can be surrounded by a figure tag, but I’m not sure about the subtleties.

Reference page: http://en.wikipedia.org/wiki/Help!_%28album%29. It has a main infobox that:

• Has a heading
• Has a thumbnail image
• Has 3 sections each separated by a faux table heading:
  • One that has a table with two columns, one with keys and other with labels, which I believe that can be done better with definition list but not sure if table is suited too
  • One that has a list of links of magazines that have reviewed the disc. I believe it is fine as is coded but still
  • One with a “chronology”, which is like a navigation menu in a table with the previous, current (no link) and next installment. Not idea if there’s an ideal way to markup it

There’s a 2nd infobox that feature a long list of links of related contents divided by some kind of table headings. I suppose it may better done by lists but there’s may be another approach. The 3rd infobox repeats the chronology noted above.

It’s a blessing and curse of HTML that there is often more than one correct answer. This is even more true with HTML5. Let’s look at the Help! album page:

• Is the infobox essential to understanding? If yes, use <figure>; if no, use <aside> (inside <article>). If this data is just a summary of information already in the article, <aside> would be appropriate. If it contains unduplicated data, I prefer <figure>. I don’t think <table> is the best container element for the infobox.
• For the “studio album” details section, either <dl> or <table> would be appropriate.
• “Professional reviews” and “chronology” both look like lists, although either could also be a table.
• I actually find the chronology formatting quite strange, as it’ll only work well for 1–3 items. Assuming this would be used for a full chronology, an ordered list would be more suitable. I guess that this is only to list the previous and next albums (a partial chronology). I don’t think it’s suitable for <nav> as the Beatles released more than three albums (but might be if all albums were listed). It’d be good to use rel="previous" and rel="next" attributes on these links.
• The blue background titles would be best represented by <h1>–<h6> titles, ideally titling each <section>.

I’m guessing the second infobox you refer to is the large table of links at the bottom of the page. This seems appropriate as a series of inline lists (ordered by time or alphabetically) in a table.

I’m also guessing the third infobox you refer to is the “US Release” one that uses the same template as the first. The first infobox notes apply here too.

Peace — Oli

No anchor elements allowed in <hgroup> elements

Daniel asked:

Consider the following code:

<hgroup>
<a href="/">
  <h1>Title</h1>
  <h2>Sub Title</h2>
</a>
</hgroup>

When using http://html5.validator.nu/ to validate my page, it says that this is invalid “Error: Element a not allowed as child of element hgroup in this context.”

I know that this validator is in beta (at least I think so), so maybe it’s wrong, but would you tell me if this is really valid or invalid? If it is invalid, would putting the anchor tags inside the heading tags fix it (despite having to use more markup

This example is in fact invalid. Only <h1>–<h6> elements can be a child of <hgroup>.

You can get around it using block-level links like so (but bear in mind some browsers have trouble with block-level links):

<a href="/">
<hgroup>
  <h1>Title</h1>
  <h2>Sub Title</h2>
</hgroup>
</a>

Hope that helps.

Rich

Using <figure> and <figcaption> as the avatar/id in a blog comment

BigAB asked:

Would this be a proper use of the figure and figcaption tags: representing the common case of avatar/username on comments (or forum entries) as a figure? Example:

<article class="comment">
   <h4>Comment on <a href="/the-blog-article">The Blog Article</a></h4>
   <figure>
       <img class="avatar" src="/my-avatar" />
       <figcaption><a rel="nofollow" href="http://my-website.exp">My Name</a></figcaption>
   </figure>
   <p>I am commenting on our blog article. This is my comment. I have much to comment on and am doing so in this comment.</p>
   <p>Thank you for letting me comment here.  I think it good that we can comment.  Feel free to comment on my comment.</p>
</article>

Doesn’t feel right to me. The spec says this:

“The figure element represents some flow content, optionally with a caption, that is self-contained and is typically referenced as a single unit from the main flow of the document.

The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc, that are referred to from the main content of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix.”

By “referred to”, I understand that to be “See figure 9″, but your example doesn’t do that. Personally, I’d just write:

<a href="#"><img alt="Bob's homepage">Bob Smith</a>

Cheers, Bruce

HTML5 Header

Josh asked:

I have read up a lot on the header element, and nesting numbered headers inside the hgroup element, and so forth. I’ve put a lot of the things I’ve seen on HTML5Doctor.com into practice on my own site, but was wondering if I can actually put the numbered header anywhere in the header, instead of having the numbered header (eg, h1-h6) first.

I was also wondering if putting links inside an h1-h6 itself would actually damage either page rank or usability. I mean, I don’t imagine how it would, but I like to be very careful, almost too careful with how I do things. I do auto-validations of all my markup constantly, and do manual validation once in a while. So, I’m a little OCD when it comes to items such as the header. Of course, putting the a element around the header itself may not hurt either – but like I said, I love to be careful.

Plus, great work on the site and the organization, folks! Some friends and myself make some articles on topics such as CSS and XHTML, more-recently HTML5, and it’s refreshing to come here to see a view from some real experts!

Thanks for your e-mail.

• <h1>–<h6> elements can go anywhere inside <header>, although we advise you to mark up your content first before thinking about CSS, so your page makes sense even without CSS.
• If you have more than one <h1>–<h6> as children of a <header>, wrap them in <hgroup>. If there’s nothing else in the <header>, just use the <hgroup> and not the <header>.
• If you only have one <h1>–<h6> and no other heading content, you don’t need either <hgroup> or <header>, although they might still be useful for a CMS template (where more stuff might be inserted) or as CSS hooks.
• Links inside <h1>–<h6> don’t affect page ranking or usability in isolation (but might affect usability if, for example, the link is to the current page).
• You can use block-level links around a <header> or <hgroup>, but test and be careful of Firefox’s vomit bug.

Finally, while we applaud your studious approach to coding, do keep in mind that HTML is quite forgiving As long as you validate occasionally and follow the spec, you’ll be fine. The web stack is a deep rabbit hole to go down, so while it’s great to do the best you possibly can, we also prescribe going outside once in a while

Peace — Oli

<code> vs <pre>

Daniel asked:

Dear HTML5doctors,

How should I markup code example correctly? I have some that are inline inside my text, I think that’s code then, but others are multi lined. I need them to be white-spaced correctly as they would get them with pre, but isn’t that semantically wrong?

Or do I put <code> inside <pre>? <pre> inside <code>? Or is <pre> to <code> as <b> is to <strong>?

Many thanks

For inline code, just use <code>...</code>, a phrasing (inline) element. For multi-line code, use <pre><code>...</code></pre>. <pre> is a flow (block-level) element. Finally, the entities &lt; and &gt; map to < and >, which you’ll need to escape inside any HTML code snippets (although you only really need to do the first one).

Peace — Oli

Got a question for us?

That wraps up this round of questions. If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.

Aside question

Lukasz asked:

I wonder if such use of aside tag inside section would be correct:

<section id="about">
  <h1>about me</h1>
  <p>blablabla</p>
  <aside>
    <h2>you can also find me on:</h2>
    <ul>
      <li><a href="#">twitter</a></li>
      ...
    </ul>
  </aside>
</section>

Thanks in advance for any help and keep up the good work!

Hard to give definitive advice without seeing the whole page, but it seems fine to me. See Mike’s article on <aside>.

In general, use <aside> for a section of a page that consists of content that is tangentially related to but separate from the surrounding content. In print, this would be a sidebar, pull-quote, or footnote. On a weblog article, this could be article metadata in the margin or the comments section.

If your social network links are main content, then <aside> isn’t the element (maybe <section>, maybe <nav>). If they’re just related content (i.e., they could be omitted when showing this page in a feed reader), then <aside> is a good choice.

peace – Oli

Blogging services

Patrick asked:

Do you have any suggestions to people implementing HTML5 on blogging services like Tumblr? The last time I checked, there are problems making HTML5 blogs on these sites:

• Tumblr – inserted iframe breaks HTML5 conformance
• Posterous – no Javascript allowed at the moment (according to their doc)
• Blogger – it doesn’t preserve my HTML5 DOCTYPE

Are there blogging services that don’t mess with the HTML5 markup?

I used to use Tumblr, and you can use HTML5 in your templates. But any new HTML5 elements (e.g., <section>) in your articles get munged, even using the “Raw HTML” setting. Unfortunately, I think that managed blogging services will probably be a little slow to adopt HTML5 (= fix the HTML5 errors they/their tools have), and you’ll have to use your own CMS for that level of control.

You can of course build your own theme for something like WordPress, and a little birdie did tell me that the latest version of WordPress has some HTML5 in its default template, so this might carry over into their hosted service. If you can’t wait and don’t have a server, remember that HTML5 is a sliding scale — I was using <div class="section"> with Tumblr for a while.

peace – Oli

Link stylesheet

Steve asked:

Hello, can we get rid of type=”text/css” when declaring a link rel=”stylesheet”?

Thank you and long live the web.

You certainly can do that. Same with including JavaScript:

<link rel="stylesheet" media="screen, projection" href="http://html5doctor.com/css/style.css">
<script src="http://html5doctor.com/js/html5.js"></script>

Thanks, Tom

ID attribute validation

Andrés asked:

Does the id attribute allows to begin with a number or a hyphen, unlike previous specs? Is there any set of character that aren’t allowed, besides space character?

There are three rules for the value of the ID attribute:

1. It must be at least one character long,
2. it must contain no space characters, and
3. it must be unique within the page.

So a hyphen would be valid as an ID value. It validates too. However, you may run into legacy stuff that hasn’t been updated yet (HTML Tidy, WYSIWYG plugins for a CMS, etc), so I’d advise testing within your workflow and in a browser (no idea if IE would barf on that, and it wouldn’t surprise me if it did).

peace – Oli

I’m so confused – article, header, footer, nav?

Benjamin asked:

Hey Doctor(s), I’m so confused right now.

I’ve been trying to implement HTML5 for my new blog and CMS, but having difficulties trying to figure out where advanced content should go. All the demonstrations and examples about HTML5 are over-simplified and just don’t include any real world information. For example, an article typically includes (in no particular order):

• Article
  • Title
  • Tagline
  • Tags
  • Avatar
  • Content
  • Links to child articles (eg. download, docs, demo)
    • Link Title
    • Link Avatar
    • Link Author Name
  • Links to recommended articles (related content)
    • Link Title
    • Link Avatar
    • Link Author Name
  • Article Author Details
    • Author Name
    • Author Avatar
  • Article Details
    • Published Date
    • Modified Date
  • Share Buttons

So all in all, way more complicated than the typical:

• Article
  • Article Title
  • Article Content

So say for example, where should all the stuff in the complicated (real-world) example go? Should the avatar go in the header, the article, or the footer? Or maybe even a details element? Should the navigation links to other articles be like: nav > ul > li > article > header > a > h1 With the a containing the link, and the h1 containing the article header? Should the post details (despite we want them display perhaps underneath the title, and before the content) be in a details element? And should that be within the header element or be below the header element? Should they use for example:

<dl>
  <dt class="published">Published At:</dt>
  <dd class="published">...</dd>
</dl>

or:

<ul>
  <li class="published">
    <label>Published At:</label>
    <span>...</span>
  </li>
</ul>

or something else? The second example seems to remove the duplication of the css class, but seems to add more complications though. Should those tag and article links in nav elements be inside the header? Or footer? Or just article? How many footers and headers can be in article?

I’m soo confused. Any help would be greatly appreciated? Perhaps the best help out there would be a detailed HTML5 example of the real-world article structure I posted above.

OK now, take a deeeep breath and relax. There, feeling a little better?

That’s a mammoth e-mail, so here are some basics to get you started:

• Start with a basic page before attempting something complex — don’t jump in the deep end.
• Look at websites in HTML5 Gallery and check their code.
• Look at the code for this site. Granted, it’s not perfect, but it’s pretty good, and we have a lot of the content you list.
• Use the most appropriate element for each piece of content, even if it’s not one of the new ones. (Hopefully it ends up being what you used before.) Perhaps our handy flowchart might help for that.

Some more specific answers:

“Should the navigation links to other articles be like: nav > ul > li > article > header > a > h1 With the a containing the link, and the h1 containing the article header?” The title of an article is not the same as an article, so it’d be wrong to use <article> or <header> here. I assume you didn’t use <h1> in navigation lists before, right?

“Should the post details (despite we want them display perhaps underneath the title, and before the content) be in a details element?” Possibly, if you wanted that interaction, but likely not as you probably want them visible all the time. See what the spec says about <details>. Decide on the semantics of each piece of content first. Worry about styling later.

“And should that be within the header element or be below the header element?” Header or footer seem like good places to put them. <label> is a caption for a form control, not an element to use whenever you need to label something.

I recommend you start with your HTML4 or XHTML1 knowledge and build on it. HTML5 is an evolution, not a revolution. In fact, I’d recommend you start out making a site in HTML4 with the HTML5 doctype (and validate it as HTML5), then change bits over time as you read each article on HTML5 Doctor and learn more

peace – Oli

Got a question for us?

That wraps up this round of questions. If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.

Server-side validation

Brian asked:

We currently use PHP-Tidy to validate the HTML mark-up of content regions of our site. Our content regions have images that represent modules in our system that get translated into code for things like processing video, forms, etc. I’ve been making the move to upgrade these modules to use new HTML5 elements, but I’m finding that Tidy is stripping out these elements and I’m doing a lot of dancing around these issues right now. Are you aware of any server-side processing scripts that have been updated to work with HTML5 and perhaps with ARIA support as well?

The current contender is html5lib. The PHP version is v0.1, so YMMV.

It seems that HTML5 support won’t be coming to Tidy anytime soon.

Good luck! Peace – Oli

Immutable image with <canvas>

Mike asked:

We do have a medical app and we want to use <canvas> to let docs draw over a still picture. The only thing I cannot do is keep the picture unchanged when they use an “eraser” (basically a white pen). I haven’t found any example on the web so may be it’s impossible. It seems that the background image either part of the canvas of a div containing the canvas becomes part of the canvas itself. If it’s possible what’s the secret? Thanks

This is possible in a variety of ways. Here’s a quick demonstration of one of the solutions. Open the demo up in Firefox 3.6 or later, drop an image in the box, draw over it, and click the “Drawn image as PNG” button to retrieve what you drew (without the background image).

Here’s what’s happening: the canvas is sitting inside of a <div> containing my still image, but I’m drawing on the nested <canvas> (I think you had it the other way around, which was causing your problems).

Hope that helps, Remy

Retrieving objects from <canvas>

DJ asked:

I wanted to know if there is any way in which the drawn objects say rectangle, circle, line, … within canvas can be identified based on the selection at later point in time (after they are drawn).

If there are no direct APIs how could we achieve it. Do we have to store the co-ordinates of each of the created object within and do the object identification based on mouse cursor? Thanks

Unfortunately, there’s no way to retrieve these objects unless you write your own system to handle it. There’s no native support for this in <canvas>.

It sounds like you actually need to use SVG, which will allow to you to hook event listeners and query the DOM tree that’s created. If you need some convincing that SVG is the right tool for the job, have a look at the Raphaël JavaScript Library. It uses SVG exclusively and is able to create some very impressive drawings and animations.

Cheers, Remy

Custom tags

Mike asked:

So by using some JavaScript I can insert unfamiliar tags into IE, and using CSS I can format them. My question is why stop with HTML5 tags like section and nav? What are the pros and cons of custom tags like <content>, <story>, <comment>, <blog> or even <mike>, <was>, <here>?

Custom elements go against having a standard like HTML5. Standards map out the set of elements, attributes, and APIs that the browsers need to implement so web developers can use them, and they provide those developers with a common approach to marking up a web page.

If custom elements were allowed, we would have an infinite number of ways to mark up content, many of which would share a common goal but require different implementations. As an example, here is a number of different elements I can dream up for some primary content: <article>, <blog>, <entry>, <post>, <page>, <main>, <primary>, <content>, <document>, <doc>, <blogpost>, <publication>, <thenameofthearticlewithnospacesorpunctuation>, <item>, <block>, <blob>, <text>, <txt>, and <paper>. Many of them are bad ideas, but hopefully you see my point. This doesn’t even account for the more predictable <contentone>, <contenttwo>, <articlefifty> that would likely also be used.

This sort of markup would make HTML a nightmare to maintain. A developer coming into an existing site would have to learn which elements have been used and what their purpose is. And it’s not just painful for developers. Browser vendors would have to find ways to parse these elements and define how they should be used. Is this element supposed to be block-level? Is it interactive? Should it impact the document outline? And what about search engines? How do they know that <myobscureelement> defines the most important content on the page, the content that should really be indexed?

Standards narrow the possibilities and ensure developers, browsers, and machines (search engines and the like) are all speaking the same language. Many people spend a great deal of time debating the specification, trying to reach consensus on which proposals should be standardized and how they should be implemented.

So stick to the standards! They exist for everyone’s benefit. As browsers continue to implement the specification correctly (even IE is catching up), our jobs will be made easier and we can spend more time creating really cool things

John Alsopp’s fantastic article Semantics in HTML5 goes into more detail about this issue. You can also see where some of the element names came from by looking at the work Hixie did researching class names in Google’s index.

Regards, Mike

The role attribute, SEO, and <hgroup>

Robson asked:

What about the role attribute? Was it dropped from specification? What will be the “role” of the role attribute in HTML5?

Today, just the home page should have the name of the site into a H1 element. On others pages, the H1 should be used to the title of the articles. How do search engines interpret the HGROUP and multiples HEADER and H1 elements today? How to implement the HGROUP and the HEADER today without impact the SEO? Thanks, guys!

To answer your first three questions, role is in. You can use it belt-and-suspenders style until assistive technology catches up with HTML5. Just be careful: “Authors may use the ARIA role and aria-* attributes on HTML elements, in accordance with the requirements described in the ARIA specifications, except where these conflict with the strong native semantics described below”.

For the second part of your question, that’s not true. You can use more than one <h1> in HTML 4/XHTML 1. It’s not advised to make every heading <h1> in HTML 4/XHTML 1 (because historically some people did that to spam), but it may be appropriate in some cases — e.g., site name and page title. Using two <h1>‘s on a single page has no effect on SEO.

With regard to <hgroup> and <header>, you’re asking the wrong question. Search engines care about high-quality, relevant content. Search engines penalise spamming, but writing markup according to the specification is not spamming. The HTML5 editor works at Google, so they’re well aware of the spec. html5doctor.com has implemented <hgroup> and <header>, and it hasn’t hurt our search engine rankings any

For more, see our articles on the header element and the hgroup element.

You probably don’t want to use <h1> everywhere anyhow, as CSS selectors are not that smart. If you wrap every <h1>-<h6> in a sectioning element (<section>, <article>, <nav>, <aside>), you don’t have to worry about keeping a logical order for your headings. Doing this means you don’t need to overwrite CSS as much. The old style, however, with the requirement to keep a logical order for your headings, still works.

Again, you’re concerned with the wrong thing. Good SEO = good content. Worrying about placement or what search engines think is a waste of time — worry about good content.

Peace – Oli

Got a question for us?

That wraps up this round of questions. If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.

The .net Awards

Held annually since 1998, the long-running .net Awards mix public opinion with those of a leading panel of 100 industry experts, including the likes of Jeffrey Zeldman, Paul Boag and Molly Holzschlag, who deliberate on the final shortlist. (Disclosure: I am a judge for this years awards, but will abstain from voting in the two categories that HTML5 Doctor is represented.)

Winners of the prestigious .net Awards 2010 are announced on Thursday, 18th November at a special event in London.

Your vote counts

Without wanting to go all Obama on you, your vote counts. To see all the categories and nominees please visit the site and vote. If that vote happens to be for HTML5 Doctor as blog of the year or HTML5 surgeons Bruce or Remy as your standards champion then we’d all be super-grateful (and one of Remy’s side projects Snap Bird, for searching twitter better, is up for best API use too).

For us to be nominated alongside some well established, fantastically popular blogs is a great achievement and one that we’re really proud of. Especially when you consider we’ve only been going for a little over a year. Anything more would be a bonus and being nominated has really invigorated us to kick on and keep producing compelling content for you guys.

For more information and the chance to vote, visit the .net awards site.