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.