We’re back with another round of patient questions about HTML5. In this article, we’ll discuss using multiple <h1>s, audio codecs, microformats, post bylines, and the <time> element.

Using multiple <h1>s

Bnonn asked:

I’m unsure of how h1 is supposed to be used now that pages can be divided into sections and articles. In (X)HTML4, a page was basically a page, and so you only had one h1 element: the top level heading for the page. I’m not even sure if that was a requirement of HTML4, or if it was just a de facto standard, but it made sense.

Now, however, there are any number of possible sections and articles per page; each of which may contain any number of heading elements (and one of those might be inside a header element). Given that h1 is a top-level heading, it seems as if each section and/or article should have one, in addition to the page-level h1. However, this contradicts what I know of accepted usage, so I’m confused about the way in which I should be marking up headings in HTML5. It doesn’t seem right to start headings in a section, for instance, with h2, because then…where’s the top-level heading for that element? But it doesn’t seem right to start them with h1, because that element in current web usage has more “power” than warrants its use there.

There is also SEO to wonder about. Even if using multiple h1 elements is right, I wouldn’t want to be penalized for it by Google. So what’s the story with that?

Any help is much appreciated.

Regards,

Bnonn

Basically, you can use multiple <h1>s in order to shape the document outline. So an <h1> within a <section> will be treated like an <h2> (if it is a nested <section>). If that <section> (and only that <section>) is aggregated elsewhere on the web, however, it will fit seamlessly into that external document’s outline. This means that your original <h1> could be treated as an <h1>, <h2>, <h3>, or <h4> as appropriate.

I hope that makes sense! Bruce’s article on the section element touches on this, and we also hope to talk more about document outlines in the future.

Cheers,

Rich

P.S. Multiple <h1>s in HTML4 are perfectly legal, but seldom used.

Audio Codecs

Adam asked:

Hello,

I’ve got a query about the issues regarding what codecs to use for the audio tag. I don’t quite get why Firefox won’t support mp3. Surely the browser calls on the codecs present on the operating system, not within the browser, so how are the licensing issues a problem to the browsers if they are simply leaving what is already present (and in theory already licensed)?

I fully admit that I am no lawyer. It just seems very odd the line of argument Mozilla has taken.

Adam Wilcox

I’m not sure why they’ve taken that stance, but I know that Mozilla only plans to support Ogg and Apple are keen to push MP3 and MP4, so we’re at stalemate. Because of this, discussion of specific codecs has been removed from the spec altogether.

Although not related to audio, see this article I wrote about YouTube and Vimeo supporting HTML5 video. It explains a little about codecs.

Sorry I can’t be of more help.

Rich

Since writing this reply there has been a lot more talk over codecs for both video and audio since Microsoft announced they would be supporting H.264 in IE9. We’ll cover this in more detail soon.

hCards

Ken asked:

How does html 5 deal with hCards and microformats in general? Specifically, can you have more than one hCard per page? As I understand it currently, having more than one is problematic. I’m asking now because of the treatment “footer” and “aside” has gotten, i.e. they are context sensitive to their “article” or “section” unless top-level, then applied to the page. Also, the use of scoped on style tags: hCards should be updated in a like manner for html 5.

Thanks for hearing me out. I don’t know if this is the appropriate place for this question, but as html 5 is much more useful, I thought maybe a post is in order

Also, “article”’s impact on the hAtom microformat makes for an interesting article, don’t ya think?

We touched upon microformats in our articles on the <address> and <time> elements, but we’ll try to cover more soon (possibly in an article on the <article> element).

I haven’t heard that having more than one hCard is problematic. I’ve certainly never had any issues doing that. If you check out the source code on the homepage of HTML5Doctor, you’ll see we’ve used multiple hCards — one for each author’s name associated with a post.

Hope that helps a little.

Cheers,

Rich

Article bylines

Eric asked:

I tweeted to you guys a few days ago (@ericdfields), wondering what you recommend for bylines for blog posts. Bylines, borrowing a newspaper term, would be the ‘Posted by SoandSo on Nov 1, 2010′ copy you find under the article of your typical blog post.

To me, they seem like something of an ‘aside’ for the header of the document.

I don’t know if its perfectly valid, but here’s the test case I whipped up.

Thanks in advance for any insight!

In my opinion, they’re header or footer information, so I do:

<header>
  <hgroup>
    <h1>Foo</h1>
    <h2>Bar</h2>
  </hgroup>
  <p>Posted by Bruce on <time datetime="2009-11-01">1st November</time></p>
</header>

Thanks, Bruce

How to use <time> with a date in astrology

Dear HTML5Doctors,

I was confused in how to using the time tag with the Astrology date. For example if I have a chunk of content like this:

ARIES: 13 Apr – 14 May

how can I use attribute “datetime” to explain the format of that date?

<p>ARIES: <time title="start" datetime="???">13 Apr</time> - <time title="end" datetime="???">14 May</time></p>

The year of birth is not fixed, please advice me some solutions about this.

Thank you,

radiz

Hi Radiz,

The time element is for one specific day, not a range or “imprecise” date. So you can’t use it for “13 April.” You need to use it for a specific “13 April” and give a year. For more, see our article on the <time> element.

Thanks, 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.

Share and Save:

Your Questions Answered #6 originally appeared on HTML5 Doctor on April 8, 2010.

Microformats are a way of adding extra semantic information to a webpage using HTML classes — information like an event’s date and time, a person’s phone number, an organisation’s email address, etc.

They aren’t a “standard” per se, but they are a widely adopted convention within the geek community. And since they use an agreed-upon set of class names, they are as compatible with HTML5 as they are with HTML4 or XHTML.

HTML5 offers one potential addition to the microformats arsenal. Because earlier versions of some microformats presented accessibility problems in the way they encoded dates and times (see an article called hAccessibility that I co-wrote with James Craig), HTML5 offers a new element for unambiguously encoding dates and times for machines while still displaying them in a human-readable way.

The format is very simple: <time datetime="2009-11-13">13 November 2009</time>:

The time element represents either a time on a 24 hour clock, or a precise date in the proleptic Gregorian calendar, optionally with a time and a time-zone offset.

You can have whatever you want between the tags, so:

<time datetime="2009-11-13">13 November 2009</time>
<time datetime="2009-11-13">13<sup>th</sup> November</time>
<time datetime="2010-11-13">Bruce's 21st birthday</time>
<time datetime="2010-11-13T20:00">8PM on my birthday</time>
<time datetime="2010-11-13T20:00+09:00">8PM on my birthday—in Tokyo</time>

are all equally valid.

Note that the last example has an optional timezone offset (+09:00) too (thanks, Oli!). You can also use “Z” (e.g. 2010-11-13T20:00Z) to represent Universal Coordinated Time (UTC), which is the equivalent of the timezone +00:00. Finally if you don’t specify a timezone offset the time is “local time” (in this case England).

The fly in the ointment

The only trouble with <time> is that the it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era. Neither can you encode imprecise dates such as “July 1904″. Microformats, however, aren’t subjected to this restriction and are often employed to mark up, for example, very old events on Wikipedia or imprecise dates on museum websites. It’s likely that authors will continue using the current, more flexible microformat patterns unless the restrictions on the <time> element are lifted. (The HTML5 working group has been continually petitioned to remove their arbitrary restrictions and widen the scope of time, but with no success).

Perhaps because of this restriction, current microformat clients can’t consume microformats such as hCalendar if they’re coded to use <time>. Stefan Schipor wrote to us saying, “The problem is that I need to parse the site with H2VX or any other similar thing for exporting. Sadly, H2VX doesn’t seem to read the datetime attribute in the <time> elements. Nor does the FF add-on Tails. I tried the microformats IRC channel and the microformateers twitter account but I didn’t get any response. Do you know if there is any support for this? It would kill me to add <abbr> elements just for it to work.”

Incorporating the pubdate attribute

This doesn’t mean that <time> is an a waste of time, or that it’s more trouble than it’s worth (a white element, as it were). It has a great deal of scope outside microformats, too.

On my personal blog, I use it to mark up publication dates of articles. There is a boolean attribute pubdate specifically for this:

<article>
  <header>
  <h1>My brilliant blogpost</h1>
  <p>Published on <time datetime="2010-01-20" pubdate>20 January 2010</time> in the Sexysocks category.</p>
  </header>
  <p>I'm wearing sexy socks! Here's a picture.</p>
  ...
</article>

The spec says:

The pubdate attribute is a boolean attribute. If specified, it indicates that the date and time given by the element is the publication date and time of the nearest ancestor article element, or, if the element has no ancestor article element, of the document as a whole.

You might be wondering why the pubdate attribute is needed at all. Why not just assume that any <time> element in an <article>’s <header> is its publication date?

Consider this example:

<article>
  <header>
  <h1>Come to my party on <time datetime="2010-03-01">1 March</time></h1>
  <p>Published on <time datetime="2010-01-20" pubdate>20 January 2010</time> in the Sexysocks category.</p>
  </header>
  <p>I'm throwing a sexy socks party at Dr Naughty's Ladyboy Cabaret Roller-disco Bierkeller Pizza-parlour-a-gogo! Do come.</p>
  ...
</article>

You’ll see that there are two dates within the <header>: the date of the actual party and the publication date of the article. The pubdate attribute is required to remove any ambiguity.

Where could time be used?

The uses of unambiguous dates in web pages aren’t hard to imagine. A browser could offer to add events to a user’s calendar. A Thai-localised browser could offer to transform Gregorian dates into Thai Buddhist era dates. Content aggregators can produce visual timelines of events.

Search engines can produce smarter search results. For example, in the recent heavy snow in the UK, I searched for school closures in my town and discovered my kids’ school was closed. After receiving a phone call from the school asking me where my kids were, I re-examined the webpage. In small print at the bottom of the page were the words "Published 5 January 2008". I expect that operators of search engines would rank more current pages more highly on searches connected with current events.

Share and Save:

The time element (and microformats) originally appeared on HTML5 Doctor on February 9, 2010.

Here we go with another post rounding up your HTML5 questions and sharing the answers with the world. We cover a wide range of topics this time, inlcluding ARIA, storage, offline capabilities, and document outlines, so read on to find the answers.

We also want to know what areas of HTML5 you’d like us to cover in future articles, so let us know!

Older browsers and XHTML

Brett Prichard asked:

If I were to use one of the new tags in HTML5, (i.e., <video> or <header>) what would happen when the page is rendered by an older browser?

The other question I have is will there be an XHTML equivalent? XHTML 2.0 breaks off compatibility with HTMLs 1-4, but will it be compatible with HTML5? I prefer to code in XHTML.

Thank you for reading.

To answer your first question: nothing special. The content nested within the element is displayed. (In the case of video, the fallback content is shown.)

Regarding your second question, I wrote about the XHTML serialisation of HTML5 a while ago.

— Thanks, Bruce

ARIA

Joseph Chapman asked:

My colleagues and I wish to switch our doctype to the streamlined <!doctype html> and implement several things we learnt from Jeremy Keith last Wednesday, primarily ARIA.

We know that support is good as long as we add an extra DTD, but we can’t find the appropriate doctype declaration to stick on the end of ...html> Any ideas? We are really keen to kick this off and use a new piece of technology that will help springboard our site to a new level of accessibility.

Any answers appreciated.

Thanks for your help.

It’s okay to add ARIA to HTML5 now without using a different doctype. I suggest you give this part of the spec a read.

I believe a task force has been created to more closely align ARIA to HTML5. We plan to cover ARIA more in a future post.

Hope this helps

— Rich

Attribute Minification

Nick Leon asked:

Hey there HTML5Doctor,

I consider myself a strong POSH developer. One of the requirements for valid XHTML is that “attribute minimization” is not allowed. HTML permits “attribute minimization”, where boolean attributes can have their value omitted entirely, e.g., <option selected>. All XML attributes must have explicit quoted values, so in XML this would be written as <option selected="selected">.

I was wondering where HTML5 stands with attribute minimization. I noticed in some of your example code, you provided the minimized form of the attribute, e.g., <audio src="elvis.ogg" controls autobuffer></audio>. Is this valid in HTML5? Would this be the valid version for XHTML5:

<audio src="elvis.ogg" controls="1" autobuffer="0"></audio>?

Those are both valid HTML5 structures (however, controls=”1″ isn’t legal; you need to say controls=”controls”).

In HTML5, you can format attributes as you please. In XHTML5 (the XML serialisation), you need to obey the XML rules.

— Cheers, Bruce

Offline storage

Kevin Searle asked:

I’m having a hard time wrapping my head around the offline storage capabilities of the HTML 5 spec. Can you consider an “HTML 5 Offline Storage 101″ article?

Just to clarify, do you mean “storage” or “offline”? They’re two very different things.

Storage relates to variables, like cookie jars but a lot bigger.

Offline applications are about detecting connectivity and possibly running your app without a connection to the Web.

We (i.e., Remy) will be writing about both of these topics, but it’s useful to know which is more in demand than the other.

In the meantime, feel free to check out the demos I’ve written at HTML5 Demos (covering offline, storage, and web databases).

— Remy

Nav Title (in the document outline)

D Ross asked:

Working on my new site and checked it with the outliner. I’m getting an “untitled section” showing up because I don’t have a headline inside my “nav” element.

Is this correct? Do I really need to title my main nav?

If so, is adding an <h5> or something similar with the words “main navigation” good enough? If so, is hiding it with display: none okay?

Thanks,

DRoss

Yes, “untitled section” is fine. I know it’s been suggested to the developer of the outliner that it should say “navigation” or something similar, but I’m not sure when or whether that will happen. (You’ll see the same thing with <aside> too if there’s no heading nested directly beneath the element).

Thanks,

— Rich

The details element

Bart asked:

Hello Doctors!

I’d like to ask you a little help with understanding the “details” element.

As the W3 spec says: “The details element represents a disclosure widget from which the user can obtain additional information or controls”.

I’m not sure if I get it right, but I think I can use this element to put details about a post (such as date and time) and controls, including “answer”, “save” and “repost”.

Please tell me if I’m wrong.

Regards, Bart

PS. I love the HTML5doctor blog, it’s so important to explain how to use HTML5. Keep up the great work!

This question triggered a flurry of responses from several of us doctors, so we’ve added them all here for you.

Answer 1

The spec says <details> is not appropriate for footnotes, and you could argue that post details are footnotes. Also, the <details> element has the option to show or hide its content, which suggests to me that it’s not appropriate for the post details.

You could possibly use a <section> or a <footer> for the post details, but I’m not clear on what you mean by “controls”.

For the date/time, you can use the <time> element:

<time class="published updated" datetime="2009-09-23">September 23rd, 2009</time>

Other doctors might have other opinions, but I hope this helps.

— Tom

Answer 2

Just to follow up on Tom’s reply: the user viewing your content can control whether or not they see the details.

The <details> element is an interactive element that is collapsed by default, so that only the heading is visible. The heading should be marked up in a <dt> element (if absent, it will read “Details”).

The control that the user agent should render (when fully supporting the <details> element) is a small triangular button to the left that, when clicked, toggles the visibility of the element’s contents.

If the <details> element should be open by default, it should have its open attribute set.

I would use <details> for any content that still allows the surrounding content to make sense while not necessarily needing to be seen. So in your example, I would put the metadata in the <details>, but not the “user controls” to reply, save, etc., since the user should always be able to see that they can perform these actions.

While the browser vendors haven’t implemented the interactive aspect of details, I, for one, will be emulating this using JavaScript.

I hope that helps (too!).

— Remy

Answer 3

You can also use pubdate as an attribute of <time>:

<time pubdate datetime="2009-09-23">September 23rd, 2009</time>

pubdate is useful when you have two different times in the post. For example, for a future event:

<article>
<header>
<h1>Gig: Hixie and the Pixies, <time datetime="2010-01-01">Jan 1st 2010</time>, Royal Albert Hall</h1>
<p>Published <time datetime="2009-09-21" pubdate>Sept 21, 2009</time></p>
</header>
<p>With Lachy on kazoo, Henri on Sousaphone, Pilgers on the triangle, and Hixie conducting</p>
</article>

I feel a post about the <time> element coming on…

— Bruce

More to come

That wraps up this round of questions! We’d like to know what areas of HTML5 you’d like us to cover in future articles, so leave a comment below or send us an e-mail.

Share and Save:

Your Questions Answered #4 originally appeared on HTML5 Doctor on December 9, 2009.

Much of HTML 5’s feature set involves JavaScript APIs that make it easier to develop interactive web pages but there are a slew of new elements that allow you extra semantics in your conventional Web 1.0 pages. In order to investigate these, let’s look at marking up a blog.

Firstly what we’ll do is use the header, footer, and nav elements to mark up the broad structure of the page. We’ll make the blog comments form much smarter by using the new data types and built-in validation available in HTML 5-aware browsers.

Then we’ll do some work on the guts of the page, using HTML 5’s article elements to better mark up blog posts and comments and show how to use the section elements to better structure accessible hierarchical headings on sites that are CMS-driven. As blogs are chronologically ordered, we’ll see what HTML 5 offers us for representing dates and times.

So take the phone of the hook, and make a cup of tea and we’ll get started.

header, footer, nav, article {display:block;}