While HTML5 has a bunch of semantic elements, including new ones like <article> and <nav>, sometimes there just isn’t an element with the right meaning. What we want are ways to extend what we’ve got, to add extra semantics that are machine-readable — data that a browser, script, or robot can use.

A lightning introduction to using microformats

For those of you that haven't used microformats before, I’ll briefly introduce some simple microformats — hopefully so simple you’ll be encouraged to use them right away!

Using rel-license for licensing information

Adding license information is quite a common activity, and while we can add a link to Creative Commons or another license easily enough, someone would have to read it to understand the content’s license:

<small>This article is licensed under a 
  <a href="http://creativecommons.org/licenses/by-nc-sa/2.0/">
  Creative Commons Attribution Non-commercial Share-alike 
  (By-<abbr>NC</abbr>-<abbr>SA</abbr>) license</a>.
</small>

If this information was machine-readable, search engines could use it to help consumers searching by license. By using the rel-license microformat to add rel="license" to the license link (indicating it’s the license for the page’s main content), we can do just that:

<small>This article is licensed under a 
  <a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/2.0/">
  Creative Commons Attribution Non-commercial Share-alike 
  (By-<abbr>NC</abbr>-<abbr>SA</abbr>) license</a>.
</small>

This article is licensed under a Creative Commons Attribution Non-commercial Share-alike (By-NC-SA) license.

This may be so easy you don’t even realise you’ve just microformatted the link! In fact, Google already uses this data to allow us to search by license (look in advanced search, in the extra options).

Using XHTML Friends Network (XFN)

Maybe we should term this one eXtensible Friends Network instead XFN is a way of specifying your relationship with people — everything from “met” to “sweetheart” — using the rel attribute on a link to their homepage.

There are two main values: (1) rel="contact" (someone you know how to get in touch with), and (2) rel="me". The rel="me" value allows you to claim ownership of your various websites, including your accounts on social networks. For example, I could have a profile with a link to my Twitter account:

<p>Oli Studholme — <a href="http://twitter.com/boblet">follow me on
  Twitter (@boblet)</a></p>

A person can infer that @boblet is my Twitter username, but by adding rel="me" we can state this relationship in a machine-readable way.

<p>Oli Studholme — <a rel="me" href="http://twitter.com/boblet">follow me on
  Twitter (@boblet)</a></p>

In order to actually work, this would need to be on my personal homepage, with the same homepage added to my Twitter profile. By doing this, a social web app that understands XFN could confirm @boblet is me, check my friends on Twitter, check if those people are already registered, and then allow me to follow them all with one click — much easier.

For more on this idea, check out Identity consolidation and the XFN rel="me" value, the RelMeAuth proposal on the microformats wiki, and Google’s Social Graph API. It seems Facebook is supporting rel="me" too.

Rel-license and XFN are simple rel-based microformats, but even with their simplicity you can see the potential power in this machine-readable stuff. Now let’s look at microformats for contact and event information.

Using hCard for contact information

Almost every website has an about page with some contact information:

<p>Oli Studholme — <a href="http://oli.jp/">http://oli.jp</a>, or 
<a href="http://twitter.com/boblet">follow me on Twitter (@boblet)</a>.</p>

Unfortunately, adding someone’s contact information to your phone or address book generally involves a lot of copying and pasting. If the data was machine-readable, however, we could use a tool to do that. Let’s add the hCard microformat to this code snippet.

<p class="vcard"><span class="fn">Oli Studholme</span> — 
<a class="url" href="http://oli.jp/">http://oli.jp</a>, or 
<a class="url" href="http://twitter.com/boblet">follow me on Twitter 
(@<span class="nickname">boblet</span>)</a>.</p>

Oli Studholme — http://oli.jp, or follow me on Twitter (@boblet).

So we’ve added a bunch of classes. There’s nothing special about that, of course, until you realise they're all part of the hCard microformat. The first one is vcard on the containing <p> element, indicating that there's hCard data here. Then we have fn, which stands for full name, url for an associated homepage, and nickname for, well, a nickname.

This is a simple example, and in fact a valid hCard only requires vcard and fn. But hCard has much more depth. We can mark up all kinds of contact-related data: addresses, company information, even a profile photo. For example, we can explicitly specify a given name and family name (this is essential for Chinese, Korean, Japanese and Vietnamese names), even middle names and titles.

<span class="vcard"><span class="fn n" lang="ja"><span class="family-name">
スタッドホルム</span>・<span class="given-name">オリ</span></span></span>

The additional n value is actually required, but can be inferred and therefore omitted for names that follow these patterns (the so-called “implied n optimisation”):

• given-name family-name
• family-name, given-name

So what’s the benefit of this? Well, there are several tools that will convert this hCard-microformatted data into a vcard file we can download and automatically add to our address book. Nifty!

It’s also recognised by Google’s Rich Snippets and Yahoo’s SearchMonkey, useful for the contact information on any company website.

Organisations, addresses, and phone numbers

Smaller company websites often have the company name and contact details in the footer, so let’s briefly see how to do that.

<p class="vcard">
<a class="fn org url" href="http://www.w3.org/Consortium/contact-keio" title="Contact Information for W3C/Keio"><span class="organization-name">W3C</span>/<span class="organization-unit">Keio</span></a><br>
<span class="adr"><a class="extended-address" href="http://www.keio.ac.jp/english/about_keio/campus_info/sfc1.html">Keio University Shonan Fujisawa Campus</a><br>
<span class="street-address">5322 Endo</span>, <span class="locality">Fujisawa city</span>,<br>
<span class="region">Kanagawa prefecture</span> <span class="postal-code">252-8520</span> <b class="country">Japan</b><br>
<span class="tel">Telephone: <span class="value">+81-466-49-1170</span></span><br>
<span class="tel"><span class="type">Fax</span>: <span class="value">+81-466-49-1171</span></span></span>
</p>

W3C/Keio
Keio University Shonan Fujisawa Campus
5322 Endo, Fujisawa city,
Kanagawa prefecture 252-8520 Japan
Telephone: +81-466-49-1170
Fax: +81-466-49-1171

By using fn together with org we can create an hCard for an organisation. Each part of the address is specified (<span>licious!), and we’ve also included a phone number (tel’s default type is voice) and fax number (specifying type and using the value class pattern).

And with Operator, we can add this hCard to our computer’s address book in one click. If you’ve ever manually added an address to your address book, you’ll love this

Using hCalendar for event information

Let’s briefly look at marking up a simple event. Here’s one I’m involved with:

<h3><a href="http://atnd.org/events/5181">WDE-ex Vol.11 —
  Designing for iPad: Our experience so far</a></h3>
<p>July 21st 19:00-20:00 at 
<a href="http://www.apple.com/jp/retail/ginza/map/">Apple Ginza</a>.</p>

Just by reading, we understand the event name, date, time, and location. But this information is difficult for computers to extract. By using the hCard microformat, it will be machine-readable.

<div class="vevent">
  <h3><a class="url summary" href="http://atnd.org/events/5181">
  WDE-ex Vol.11 — Designing for iPad: Our experience so far</a></h3>
  <p><span class="dtstart"><abbr class="value" title="2010-07-21">
  July 21st</abbr> <span class="value">19:00</span></span>-
  <span class="dtend"><span class="value">20:00</span></span> at 
  <a class="location url" href="http://www.apple.com/jp/retail/ginza/map/">
  Apple Ginza</a></p>
</div>

WDE-ex Vol.11 — Designing for iPad: Our experience so far

July 21st 19:00-20:00 at Apple Ginza

We’ve added vevent on a wrapping element to indicate this is an hCalendar. Events are required to have a summary and a starting time, so we’ve added summary and indicated the starting date and time using dtstart. While historically datetimes were indicated using <abbr title="">, the required ISO 8601 format (for example “2010-07-10T19:01:29”) is very unfriendly to screen readers. Imagine having those numbers read to you! For this reason, the hCalendar specification recommends either breaking the datetime into separate date and time pieces, using the value class pattern, or possibly doing both. The specification is also smart enough to know that if the end datetime dtend is only a time, then it’s on the same day, so we don’t need to specify the date again, although tool support for this is spotty. Finally, we’ve added some URLs, one of which is for the event’s location.

With this data now being machine-readable, we can do things with it. For example, we can add the event to a calendar app with one click.

<time datetime="2010-07-21T19:00:00+09:00"><span class="dtstart">
  <abbr class="value" title="2010-07-21">July 21st</abbr>
  <span class="value">19:00
</span></span></time>

Extending HTML5 — Microformats originally appeared on HTML5 Doctor on August 17, 2010.

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.