<h1>My fantastic site</h1>
<h2>About me</h2>
<p>I am a man who lives a fascinating life. Oh the stories I could tell you...</p>
<h3>What I do for a living</h3>
<p>I sell enterprise-managed ant farms.</p>
<h2>Contact</h2>
<p>Shout my name and I will come to you.</p>

<h1>My fantastic site</h1>
<h1>About me</h1>
<p>I am a man who lives a fascinating life. Oh the stories I could tell you...</p>
<h1>What I do for a living</h1>
<p>I sell enterprise-managed ant farms.</p>
<h1>Contact</h1>
<p>Shout my name and I will come to you.</p>

<h1>My fantastic site</h1>
<section>
  <h1>About me</h1>
  <p>I am a man who lives a fascinating life. Oh the stories I could tell you...</p>
  <section>
    <h1>What I do for a living</h1>
    <p>I sell enterprise-managed ant farms.</p>
  </section>
</section>
<section>
  <h1>Contact</h1>
  <p>Shout my name and I will come to you.</p>
</section>

<h2>HTML5 Doctor articles</h2>
<article>
  <h1>The section element</h1>
  <p>We doctors are a bunch of chums using HTML5 and writing about how we do it...</p>
</article>
<article>
  <h1>The article element</h1>
  <p>We’ve discussed a lot of new elements here at HTML5Doctor...</p>
</article>

<h1>HTML5 Doctor articles</h1>
<article>
  <h3>The section element</h3>
</article>
<article>
  <h3>The article element</h3>
</article>

<h2>HTML5 Doctor articles</h2>
<article>
  <h2>The section element</h2>
</article>
<article>
  <h2>The article element</h2>
</article>

<h6>HTML5 Doctor articles</h6>
<article>
  <h1>The section element</h1>
</article>
<article>
  <h1>The article element</h1>
</article>

<aside>
  <section>
    <h2>Twitter</h2>
  </section>
  <section>
    <h2>Recent comments</h2>
  </section>
</aside>

<aside>
  <h1>What you're saying</h1>
  <section>
    <h2>Twitter</h2>
  </section>
  <section>
    <h2>Recent comments</h2>
  </section>
</aside>

<article>
  <hgroup>
    <h1>Title goes here</h1>
    <h2>Subtitle of article</h2>
  </hgroup>
  <p>Lorem Ipsum dolor set amet</p>
</article>

<h1>Top of the outline</h1>

<section>
  <h2>A heading in the outline</h2>
  <p>Lorem ipsum dolor sit amet...</p>
</section>
<section>
  <h2>Another heading in the outline</h2>
  <p>Lorem ipsum dolor sit amet...</p>
  <blockquote>
    <h1>This quoted heading will not appear in the outline</h1>
    <p>Lorem ipsum dolor sit amet...</p>
  </blockquote>
</section>

Document Outlines originally appeared on HTML5 Doctor on July 12, 2011.

At the moment, Google indexes HTML5 microdata (more about microdata) but does not reward you for using the new HTML5 structural elements, but neither does it penalise you:

As HTML5 gains in popularity and as we recognize specific markup elements that provide value to our indexing system, this is likely to change, but at the moment I would not assume that you would have an advantage by using HTML5 instead of older variants….

Personally, I would recommend using HTML5 where you think that it already makes sense, perhaps reverting to HTML4 if you can determine that the browser won’t support the elements of HTML5 that you use properly. While this will not result in an advantage for your content in our search results, it generally wouldn’t be disadvantageous either.

But they will take account of HTML5 once it becomes widespread, and they seem to be encouraging experimentation:

Our general strategy is to wait to see how content is marked up on the web in practice and to adapt to that. If we find that more and more content uses HTML5 markup, that this markup can give us additional information, and that it doesn’t cause problems if webmasters incorrectly use it (which is always a problem in the beginning), then over time we’ll attempt to work that into our algorithms….

HTML5 is still very much a work in progress, so it’s great to see bleeding-edge sites making use of the new possibilities

The Doctors’ advice on SEO is to follow Google’s time-honoured guidelines: write valid, cross-browser, accessible HTML, don’t misuse markup or “cloak” with CSS, make a site with a clear hierarchy and text links, and write good content:

Create a useful, information-rich site, and write pages that clearly and accurately describe your content.

Happy New Year. May your hat remain white.

HTML5 microdata and schema.org

Added October 2011:

Schema.org is a consortium of Bing, Google and Yahoo!. On its website it says

[schema.org] provides a collection of schemas, i.e., html tags, that webmasters can use to markup their pages in ways recognized by major search providers. Search engines including Bing, Google and Yahoo! rely on this markup to improve the display of search results

schema.org uses HTML5 microdata with new elements like <time>. So, yes: in this special case (using these markup patterns) will ensure that this HTML5 will assist search engines to categorise your content (which is not the same as guaranteeing a higher ranking, of course).

Multiple <h1>s on a page

The new HTML5 outlining algorithm allows multiple <h1>s in a page. We get lots of questions about whether developers will be penalised by Google which, according to myth, disallowed this.

I say “myth” because Google has always allowed multiple <h1>s on a page, provided that it’s organic rather than trying to game the system, as this video shows:

However, don’t go too crazy with the <h1>-only approach as it removes any hierarchy from your pages in browsers that don’t implement the outline algorithm and screenreaders that sit on top of them.

HTML5 and Search Engine Optimisation (SEO) originally appeared on HTML5 Doctor on January 11, 2011.

How would you code the URL of a person leaving a comment (assuming they provided one)? Remember that there may be multiple comments on any one page. Also note that we’re not going to worry about what element wraps each comment this time. Choose from the five options below, and explain your rationale in the comments.

A:

<header>
Comment by <a href="http://www.myspace.com/timbo/">Tim 
Berners-Lee</a>
</header>
WTF! LOL! U SUCK! KTHXBAI!

B:

<header>
Comment by <cite><a href="http://www.myspace.com/timbo">Tim 
Berners-Lee</a></cite>
</header>
WTF! LOL! U SUCK! KTHXBAI!

C:

<header>
Comment by <a href="http://www.myspace.com/timbo"><cite>Tim 
Berners-Lee</cite></a>
</header>
WTF! LOL! U SUCK! KTHXBAI!

D:

<footer>
Comment by <address><a href="http://www.myspace.com/timbo">Tim 
Berners-Lee</a></address>
</footer>
WTF! LOL! U SUCK! KTHXBAI!

E:

<h1>
Comment by <a href="http://www.myspace.com/timbo"><address>Tim 
Berners-Lee</address></a>
</h1>
WTF! LOL! U SUCK! KTHXBAI!

Your answers below, please, and show your working out. We’ll close comments and give our opinions on Wednesday 22 December.

Rules: It is THE LAW that you read the preceding comments before adding your own. Note: please DON’T USE ANGLE BRACKETS in your comments. Escape them with &lt; and &gt; or just use [foo] – we’ll know what you mean.

HTML5 Simplequiz 5: URLs of commenters originally appeared on HTML5 Doctor on December 17, 2010.

With Dan’s blessing, we’re running an occasional series of HTML5 Simplequizzes.

HTML5 offers a way to associate a figure (which can be an image, a video, a graph, a table, a pull-quote) with a caption using the <figure> element. This is very common in print, but there has been no way to do this in HTML4, as there is no element that groups a figure and a caption (other than a semantically-empty <div>).

Our question this week is about alternate text for images that are captioned. I’ve gotten this wrong before (in print, embarrassingly), as have two highly-clueful friends of mine. The man who set us right will be your moderator and quizmaster this week, Steve Faulkner of The Paciello Group, possibly the most respected accessibility agency out there.

We have an image as a figure in a story simply about a dignitary opening a new branch of Mr Lidl’s marvelous emporium. The caption will be “Mayor of Casterbridge opens a new Lidl supermarket”.

What’s the best markup for this? Show your working out.

A:

 <figure>
 <img src=blah.png
  alt="A portly gent cuts a ribbon. He is with five small children, and is watched by two middle-aged woman, a very tall smiling man, and a small crowd">
  <figcaption>
  Mayor of Casterbridge opens a new Lidl supermarket.
  </figcaption>
 </figure>

B:

<figure role=img aria-labelledby=lidl>
<img src=blah.png alt="">
 <figcaption id=lidl>
  Mayor of Casterbridge opens a new Lidl supermarket.
 </figcaption>
</figure>

C:

<figure>
<img src=blah.png>
 <figcaption>
 Mayor of Casterbridge opens a new Lidl supermarket.
 </figcaption>
</figure>

D:

<figure>
<img src=blah.png alt="">
 <figcaption>
 <p>Mayor of Casterbridge opens a new Lidl supermarket.</p>
 </figcaption>
</figure>

E:

<figure>
<img src=blah.png alt="Mayor of Casterbridge opens a new Lidl supermarket.">
 <figcaption>
  Mayor of Casterbridge opens a new Lidl supermarket.
</figcaption>
</figure>

Steve will wrap up the quiz next Thursday.

HTML5 Simplequiz #4: figures, captions and alt text originally appeared on HTML5 Doctor on November 5, 2010.

With Dan’s blessing, we’re running an occasional series of HTML5 Simplequizzes. And here’s the second, suggested by a reader named Alohci.

It’s easy to cite works in HTML and default browser stylesheets obey the typographic convention of showing the citation in italics:

<p><q>There was a young man from Nantucket</q> 
wrote John Keats in his <cite>Ode on a Grecian Urn</cite>.</p>

(Although if you also link to an online copy of the work, do you put the link inside the cite element, or the cite element inside the <a>? Oops, that’s another discussion.)

But how do you mark up the author of the work cited — in this case, the text “John Keats”?

Choose from the answers below please. Make sure you show your working out.

A:

<b>John Keats</b>

B:

<i>John Keats</i>

C:

<cite>John Keats</cite>

D:

<span style="font-style:italic">John Keats</span> 

E:

none of the above, and I shall leave a comment to tell you why each of the above is entirely preposterous

Your answers below, please, with your rationale. I’ll wade in on Thursday 14th October.

Note: please DON’T USE ANGLE BRACKETS in your comments. Escape them with &lt; and &gt; or just use [foo] – we’ll know what you mean.

HTML5 Simplequiz #2: citing people originally appeared on HTML5 Doctor on October 8, 2010.

Headers and sidebars

Ad asked:

Hello,

I have 2 questions:

1. If I have my main navigation above the masterhead would best practise be having the nav tag inside of a header tag with the h1 and h2 in a hgroup? Or should the nav and header tag be separate?

2. I am building a blog in HTML5. It has a blog-like sidebar with articles, contact info and about info in it. Would the best tag to wrap this in be section or aside?

Thank you so much for your time,
Ad Taylor

Placing your <nav> within your <header> is fine and valid. However, if it makes more sense to leave it outside, then you can do that too. You don’t need to put the <hgroup> inside the <nav> though.

See our articles on <header> and <nav> for more on this.

Regarding your second question, I would use <aside> (as we’ve done on the HTML5 doctor site) and then use multiple sections within that. Also see Bruce’s article on Designing a blog with HTML5.

Hope that helps.

Cheers, Rich

HTML5 <img> element

Martijn asked:

As you are, according to the slogan, “helping [me] implement HTML5 today,” I thought to bother you people with a spec. related question.

What should an UA do with an image without specified width and height attributes?

The dimension attributes part of the specification keeps stating “if specified” for every rule but doesn’t give any “if not specified”.

The part of the specification defining the img element itself does not state anything of importance about the dimension attributes apart from how the attributes in the DOM should be created by the UA.

Interesting is to note that they have omitted these attributes in all their img element examples.

In the dimension attribute section they go state the following.

– The dimension attributes are not intended to be used to stretch the image.

So we can only use them to make images smaller? This is odd as well so let’s say by stretch they mean to say both expending and shrinking in size. In this case the attributes can only be used for two cases:

1. To state the exact width and height of the image. Something that seems redundant unless not using those attributes means the UA can display the image at any size (which it might, as nothing about this is defined in the spec.).

2. To give a 0 in both attributes. By this I am telling the UA that the image is not to be seen by the user.

Am I missing something or is the specification missing this?

Looking forward to getting your prescription

Kind Regards, Martijn

If no dimension attributes are specified, the browser will leave no space for the image, and once the image has been loaded (after the rest of the page), it will then need to reflow the entire page, as that’s the first time it knows the size of the image. This can cause the content you’re reading scrolling off the page.

If you give the size of the image as attributes in the HTML, the browser will leave space and render the image there once it’s loaded without reflowing the page. On a mobile phone, reflowing the page unnecessarily drains the battery, and users can get vertigo from the page’s text jumping around to accommodate images.

Thanks, Bruce

Section and Sectioning

Yanoo asked:

Hi,

What do you mean when you are talking about “sectioning”? And why don’t header and footer require sectioning?

I think about section and sectioning like about part of something defined. News, comment, page content, sidebar, *header*, and *footer*. Is it bad representation?

Sectioning relates to the headings in some block of related content and defining what is related to what in a hierarchy of headings (<h1>–<h6>). The outlining algorithm can produce a table of contents from the nested <section>, <article>, <nav>, and <aside> elements.

Headers and footers themselves do not change the outline; a header or footer may contain no headings. If a header or footer does contain a heading, then that heading does come into the outline. See our article on the section element.

Thanks, Bruce

Scaling the Video

Ian asked:

Hi there,

Not sure if this question is an appropriate one, but any help would be really appreciated.

I’m going about updating my video website, chutney.ie, and would love to implement HTML5. I am interested in replicating the scaling effect/style used on the Mozilla welcome page.

Not being overly knowledgeable in this area, I would love to know how to begin — is this effect a Flash based animation, or something that can be achieved with HTML alone?

Again, any nudge in the right direction would be great.

Many thanks,

Ian

I’m not sure how Mozilla did it, but you can use some of the Webkit and Mozilla transforms on the <video> element. For example, you can cause the video to grow on hover — see this example in Chrome, Safari, or Opera. You can also use the :target pseudoclass to initiate animations. Alternatively, you can use a JavaScript onClick event to create the same effect.

You can also combine <video> and <canvas> to provide some interesting results (laying the <canvas> over the <video>). For more on the <video> element and what it can do, please read the Introduction to HTML5 Video on dev Opera written by Bruce Lawson and Patrick Lauke.

Cheers, Rich

We need a <field> tag

John wrote in and proposed a field element:

Hey there. First off thanks for the site. I was excited to find it. I spent a little time on the W3C site and honestly couldn’t figure out how to submit suggestions there. So going to submit mine to you guys and maybe you can pass it on (if it is good) or point me to someone that can help. Ok to the point:

We are getting nice new tags to with HTML5 (nav, footer, etc) to help us create more semantic code. I think what we really need is a field tag — after all what are fieldsets sets of?

Everyone wraps up their labels and inputs with some element. Some of us do this with UL, some people do it with DT/DD, some with DIVs and some people out there insist that a form is tabular data.

We are all just bastardizing these elements because there is no clear semantic wrapper for field elements of a form.

I think you get the point. I’m trying to keep this email short. If you think there is anything to this argument, I have a more detailed summary (with example code) at:

http://john.mirick.me/2009/10/what-is-really-set-of-shouldnt-we-have.html

I would love to hear your thoughts on this.

Thanks!
John

While a field element would be nice — it would stop the argument over how best to mark-up forms — you have to ask yourself whether or not it actually adds any semantic or functional value to an HTML document. Yes, wrapping inputs and their labels in a field would make things easier to read and drop the need for the for attribute on the label (since the relationship can be assumed), but doing so would not be backwards compatible. In theory, we could continue to add for until there is a suitable time to drop it, but again I question the value of such a tag.

The purpose of wrapping form input/label pairs is generally to ease styling. My personal stance is that unless there are case studies showing how such an element can add more value to HTML forms, this proposal won’t make it very far.

Regards, Mike

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.

Your Questions Answered #5 originally appeared on HTML5 Doctor on March 2, 2010.

However I ran in to some very serious issues with the tag, so serious, in it’s current state, it’s unusable.

Overview of the details element

The details element, by default, is a collapsed element whose summary, or label, is the first child legend (if no legend is used, the UA provides a default, such as “Details”), with a triangular button to indicate it’s current open state.

If you include the open attribute, then the element is open by default. In theory, you could attach a click event to the legend, and switch the open attribute.

The markup would roughly be this:

<details open="open">
  <legend>Terms & Conditions</legend>
  <p>You agree to xyz, etc.</p>
</details>

Here’s the details test page I was working from: HTML 5 details test

The issues

The biggest problem, and the show stopper for me, is that the browser’s treatment of the legend element completely breaks this markup pattern – this is true for all the major browsers: Opera, Safari, Firefox and IE (tested in all the latest and some older browsers). I’ll go in these issues in detail in a moment.

Other problems include:

• Styling the legend element is exceptionally difficult, particularly positioning
• Using the WHATWG guidelines to styling the details element prove both difficult to interpret and difficult to implement.
• When using CSS to style the open state of the details element using: details[open] { height: auto; }, meant that once I changed the open state using JavaScript, it wouldn’t trigger the browser to redraw (as it would if I had added a class). I’ve run in to this before, CSS 2.1 is styling source, not the DOM.

Legend treatment

Surprisingly Firefox is the worst one out in these issues, the rest of the browsers have fairly same treatment of the issue. In the screenshots, I’ve included a fieldset and nested legend for reference.

Internet Explorer

IE7 & IE8 closes the legend element it encounters when it’s not inside a fieldset element and move it’s contents out to an adjacent text node.

What’s also strange, is that looking at the DOM it also creates another empty(?) closed legend element after that text node. It doesn’t have any effect, but just looked odd:

Opera

Opera (9 & 10b) is very similar to IE in it’s treatment of the legend in the details element, except it doesn’t create the second closing legend node. It just closes the legend, and creates the adjacent text node.

Safari

Safari simply strips the legend all together out of the DOM. So much so, that if you open the web inspector, then the error console, you’ll see it warning out that it’s encountered an illegal element, ignoring it, then encountering the closing tag, so it ignores that too. You’re left with just the text node.

Firefox

The best for last. Firefox goes one step beyond the other browsers. It assumes you’ve forgotten to include the fieldset element. So when it hits the legend element, Firefox inserts an opening fieldset up until it finds (I believe) the closing fieldset element, which obviously it doesn’t so the result is the rest of the DOM, after the first illegally placed legend ends up eaten by fieldset element, which leaves my DOM in a mess:

Impact on other elements

details isn’t the only element that reuses the legend element for labelling, the figure element also is supposed to support the legend element. The result is obviously going to be the same.

Conclusion

We can’t style the legend element when the text is being thrown out by all the browsers, and Firefox’s DOM mangling is just too painful to look at.

This basically means that we can’t, in any reasonable amount of time, use the legend element inside both the details and figure element in the spec’s current state.

For me, I’ll be using an alternative element, probably just a p element styled to look like a legend, but that’s really not the point. Ideas anyone?

It turns out we weren’t the only ones looking at this and Ian Hickson has responded on the issue:

My plan here is to continue to wait for a while longer to see if the parsing issues can get ironed out (the HTML5 parser in Gecko for instance solves this problem for Firefox). If we really can’t get past this, we’ll have to introduce a new element, but I’m trying to avoid going there.

It’s fine to think that Gecko will update, but it’s IE that I’m worried about, they won’t turn out their render engine, and the result is we’ll have to avoid using the legend in any element other than fieldset.

Legend not such a legend anymore originally appeared on HTML5 Doctor on July 31, 2009.

HTML 5 in 5 seconds

It’s über easy to get your markup to validate as HTML 5 — just change your DOCTYPE from whatever it is now to this:

<!DOCTYPE html>

That's it! It doesn't require anything more than that.

Google are doing it already. Check out their homepage, written all in one line:

<!doctype html><head><title>HTML 5 - Google Search</title><script>...

Ironically, Google's search and results pages don't validate because of their use of invalid tags like <font> and a number of other errors, but that's okay. They can still take advantage of the HTML 5 parsing rules (e.g., no type attribute on the <script> element) by using the correct DOCTYPE.

HTML 5 minified

If you like to knock out quick prototypes or experiments that don't require much styling, you might be interested in a miniature document in HTML 5:

<!DOCTYPE html>
<title>Small HTML 5</title>
<p>Hello world</p>

That's completely valid HTML 5 too.

(Interestingly, there was some disagreement about this pattern's validity when I removed the <title> tag. Hixie's DOM viewer says it's fine, and so does the W3C validator as long as the markup is entered manually. But Henri Sivonen's validator says it's invalid without the <title> tag. The W3C validator also says it's invalid when you give it a url. Hopefully, this will get sorted out soon.)

HTML 5 complete & compatible

This final, more complete boilerplate also indicates the character set. Without it, some characters will not render properly (and I've spent too much time in the past trying to work out why!).

We're also including the HTML 5 shiv so that we can style elements in IE. Note that you must include this script in the <head> element.

Finally, we're adding a few CSS rules to cause the new block-level elements to render as such, since some browsers don't know about them natively.

So here it is — a valid and complete HTML 5 document boilerplate:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>HTML 5 complete</title>
<!--[if IE]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
<style>
  article, aside, details, figcaption, figure, footer, header,
  hgroup, menu, nav, section { display: block; }
</style>
</head>
<body>
<p>Hello World</p>
</body>
</html>

If you want to experiment with HTML 5, the default JS Bin template is an HTML5 boilerplate for you to play with too.

HTML5 Boilerplates originally appeared on HTML5 Doctor on July 17, 2009.

At first, I thought the <nav> element to be pretty simple. And whilst it still is very easy to use, I found the specification to not be overly helpful; a lot of decisions are left to the developer. Then on Monday Hixie made a change to the definition of <nav> in the draft following a prompt from our very own Dr Bruce.

How to use it

You are probably used to using something like

<div id="nav">
<ul>
<li><a.... etc

Or

<ul id="mainNav">

Well, for the sake of your markup, nothing much will change as you will now have something like this

<nav>
<ul>
<li><a href="index.html">Home</a></li>
<li><a href="/about/">About</a></li>
<li><a href="/blog/">Blog</a></li>
</ul>
</nav>

The specification

The HTML 5 specification defines <nav> as:

The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. Not all groups of links on a page need to be in a nav element only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a list of links to various key parts of a site, but the footer element is more appropriate in such cases, and no nav element is necessary for those links.

The key phrase there is “major navigation” (previously primary navigation).

Looking at the example they give – “In the following example, the page has several places where links are present, but only one of those places is considered a navigation section.”

<body>
<header>
<h1>Wake up sheeple!</h1>
<p><a href="news.html">News</a> -
<a href="blog.html">Blog</a> -
<a href="forums.html">Forums</a></p>
<p>Last Modified: <time>2009-04-01</time></p>

<nav>
<h1>Navigation</h1>
<ul>
<li><a href="articles.html">Index of all articles</a></li>
<li><a href="today.html">Things sheeple need to wake up for today</a></li>
<li><a href="successes.html">Sheeple we have managed to wake</a></li>
</ul>
</nav>

</header>
<article>
<p>...page content would be here...</p>
</article>
<footer>
<p>Copyright © 2006 The Example Company</p>
<p><a href="about.html">About</a> -
<a href="policy.html">Privacy Policy</a> -
<a href="contact.html">Contact Us</a></p>
</footer>
</body>

I have to say that this is no use to me. There are six items of navigation in the header element there. But only three are in the nav tag. There is no explanation as to what differentiates the first three links with the second three links – both go to different pages and all are in internal to that current site.

They also give a second example:

<body>
<h1>The Wiki Center Of Exampland</h1>

<nav>
<ul>
<li><a href="/">Home</a></li>
<li><a href="/events">Current Events</a></li>
...more...
</ul>
</nav>

<article>
<header>
<h1>Demos in Exampland</h1>

<nav>
<ul>
<li><a href="#public">Public demonstrations</a></li>
<li><a href="#destroy">Demolitions</a></li>
...more...
</ul>
</nav>

</header>
<section id="public">
<h1>Public demonstrations</h1>
<p>...more...</p>
</section>
<section id="destroy">
<h1>Demolitions</h1>
<p>...more...</p>
</section>
...more...
<footer>
<p><a href="?edit">Edit</a> | <a href="?delete">Delete</a> | <a href="?Rename">Rename</a></p>
</footer>
</article>
<footer>
<p><small>© copyright 1998 Exampland Emperor</small></p>
</footer>
</body>

This is a little more helpful as I find the biggest isse of the <nav> element is deciding which sets of links should be classed as major navigation.

Where to use it?

If you take a peek at the source code for this site, there are three uses (Ed. or four if you’re on a page that includes pagination) of the nav elements – we used it on the main navigation and above the footer (both are exactly the same links by the way). We also decided to use it on the skip links that are included for accessibility.

Looking at the content of the site, it could be argued that the <nav> element could be used on the Recent Articles and Categories listings in the sidebar. Should you do it? Honestly, I think it is hard to say from looking at the spec – but I would say these are not “major navigation” but it would tempting to do, particularly if you’re analytics suggest these areas of navigation are ‘major’ ways in which your users navigate your site.

Other Possible Uses

Below are a few more examples of other areas of the site in which you might consider using the <nav> element. It is also important to note that while XHTML 2 <nl> element, this hasn’t been replicated in HTML 5 because navigation does not have to take list form, as we’ll see.

• Table of Contents
  I would say definitely yes to that – it is primary navigation for that particularly content
• Previous/next buttons (or pagination)
  I would say yes to this because it is important to the overall structure and hierarchy of the blog/site
  
• Search form
  For me, a definite yes, but it is not mentioned in the spec. A search form is hugely important to the navigation of a site, particularly large sites which rely almost solely on their search engine.
  
• Breadcrumbs
  Again, I would say yes to this as well. Although breadcrumbs are not always necessary and can be used when not applicable, on large sites a breadcrumb trail can be an important navigation aid.

The difference of nav from menu

If you aren’t aware there is another element that can confuse the issue in the HTML 5 specification – menu. I’ve noticed that some developers are using the <menu> element for navigation rather than the <nav> element. We thought it best to clarify that <menu> is to be used for a list of commands and is an interactive element and more likely to be used exclusively in Web Applications. We will be covering more about the <menu> element in a later post.

And finally…

Only with the help of the community, and hopefully a much clearer spec, can we be sure when and perhaps more importantly, when not to use the <nav> element.

Semantic navigation with the nav element originally appeared on HTML5 Doctor on July 15, 2009.

But you might not. You might want SHOUTY UPPERCASE tags, no trailing slashes and attribute minimisation. And, in HTML 5, you can choose.

Thanks to the “pave the cowpaths” principle, it’s up to you. As you like it. What you will. Whatever you want, whatever you like.

But let no-one tell you that HTML 5 kills XML—meet XHTML 5.

XHTML 5 is the XML serialisation of HTML 5 and, as you’d imagine, it has all the stricter parsing rules that you’d expect (and are used to if, like me, you grew up with XHTML DOCTYPES). It must be served with an XML MIME type, such as application/xml or application/xhtml+xml (so no rendering in Internet Explorer for the moment) and will throw a wobbly at the slightest well-formedness violation. (See Serving XHTML with the Right MIME Type for more information.)

Usual XML rules apply: no document.writes allowed, no DOCTYPE required, some syntax and script differences to trip up the unwary and you can use namespaces.

The main differences are summarised on the official WHATWG wiki Differences Between HTML and XHTML. It’s also possible to write polyglot documents that can be processed as either by browsers, depending on the MIME type used.

Magne emailed the Doctor to ask “Is it OK to use HTML5 tags in a page with the XHTML 1.1 doctype? Which one should I use, as in, which one is the recommendation now?”

If you want to use the new features, you need to use HTML 5 DOCTYPE or XHTML 5. Given that Internet Explorer cannot process XML, for pragmatic reasons the Doctor advises HTML 5.

HTML 5 + XML = XHTML 5 originally appeared on HTML5 Doctor on July 2, 2009.