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!

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.

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.

Getting info from a canvas to the server

Stephen asked:

I want to use a canvas element as a layout plan and allow people to move things about and the like but I then want to be able to submit the changed layout to the server so it can be kept not just as a bitmap but as the various current layout of the plan. Is this possible?

You could call canvas.toDataURL() and store this output on the server. (Note that canvas is the DOM node and not the 2D context.) This will store the current state of your canvas, but it’s effectively a bitmap at this point. If you want to store the element for later editing, I’d suggest you use SVG instead. You can achieve the same graphical effect, but you’ll have access to the actual vector data since it’s XML.

Hope that helps,

Remy

Progress or meter?

Pierre asked:

Hello doctor,

I’m beginning with HTML5. I just wonder if I’m using the progress and meter elements correctly. Just imagine a player. Is it correct to use: the progress element to specify a load bar; the meter element to specify the volume set.

Thank you Doctor, have a good day. :-)

<progress> is spot on for a loading bar, yes.

<meter> is read only, however, so it’s not appropriate for a volume control. There are some examples in Tom’s article on <meter>. To create a volume control, you could use one of the new input types specified in HTML5, perhaps <input type="range">.

Cheers,

Rich

Headers

Brad asked:

Having read you can use the header tag within almost any other element, is it fair to say you no longer “design” the header but simply design the elements in each header? How does that work? Would you use header classes?

In the past you define your header with an image or text etc. You can no longer do that if you use multiple headers?

The <header> element should be used if you have any related information within the “header” of that section that needs to be grouped. This means, for example, it isn’t necessary to wrap a lone <h1> in a <header> element. Also remember that the header doesn’t have to appear at the top of a section of page.

Our articles on the <header> element and <hgroup> element explain this some more.

Whether you need to use classes depends on your site.

Ta,

Rich

The placeholder attribute

José asked:

I recall once having seen text inputs that had tips inside them. They didn’t need Javascript in order to manage those tips. Would you consider discussing that a little better? That’d be great! Thanks!

We’re publishing an article on forms shortly, so be sure to look out for it.

Meanwhile, you’re looking for the placeholder attribute. Currently, this is supported only on Webkit browsers, although Mozilla is also working on it. You can use placeholder like this:

<input placeholder="Search" title="Type your search here" ...>

We’ve also written a JavaScript solution using feature detection (i.e., it will check whether the browser supports placeholder and adds support if not). Just add this script to the end of your markup (note that it should be the end since it needs to run once the DOM is ready).

Hope that helps,

Bruce & Remy

HTML5 Minified

Grant asked:

Hello! Big fan of your website. I wanted to know about the so called “HTML Minified” feature that allows you to strip the html, head and body tags from your page.

The W3C Validator Conformance Checker for HTML5 says this is valid, but the Conformance Checker is beta and is supposedly unreliable. I haven’t heard from anywhere else that stripping these tags is a feature.

So is it really a feature? Or just a bug (A BIG one at that) in the experimental validator? I know that it works, but I would like to see any confirmation other than the validator that this is in fact an intended standard before I start using it on my websites. Thanks!

According to the spec, it is now explicitly permitted to omit all kinds of elements tags, including the ones you mention. Browsers are able to deduce the document structure based on context (e.g., some elements are only allowed within a <body> element) and will fix the DOM as they go. In fact, these have always been optional tags in HTML (but not XHTML).

Browsers are so good at this, though, because they’ve had to deal with the pants code out there on the interwebs. Going this route means you’re relying on browser error handling to render your document (although said error handling has admittedly been standardised in HTML5). I personally see it as a more extreme version of quoting element attributes. Of course you don’t have to, but being strict makes errors much easier to find, helps out parsers that may not be as sophisticated as a full-fledged browser (like text editor syntax highlighting), and makes it easier for beginners and veterans alike to learn and use HTML.

In general, machines understand you better when you’re explicit, so I’d advise against omitting these elements.

For more detailed articles on HTML5 minification, check out Remy’s HTML5 Boilerplates and Bruce’s A minimal HTML5 document.

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.