The good thing about the microdata (itemscope, itemtype, itemprop, etc.) part of the HTML5 spec is that it is part of the HTML5 spec; it’s built right into HTML5. That really is a good thing. On the other hand, it’s yet another competitor in the semantic lineup and it’s a newcomer in a spec that’s not entirely finalized.

It may end up being a better way to add semantic meaning to our HTML documents than microformats, due to its integration with HTML5.  Only time will tell, and I personally won’t have a strong opinion until I’ve attempted to use it in a variety of real-world situations.  So, in this post, I won’t make any comparisons to RDFa (which it’s not entirely incompatible with),  I won’t comment about namespaces, etc.  This post isn’t about the theoretical rigor of HTML5 microdata — it’s just about how to use it alongside other semantic options, like the hCard microformat, to add semantic meaning that is machine readable.

On that note–my understanding of HTML5 microdata (which I may refer to as “item stuff”) suggests that it is not meant only or necessarily to be a “microformat killer”, or to replace RDFa, but one of its possible applications certainly is duplicating some of the “functionality”* of each.

Google is already starting to support “item” parsing (and I’m sure others will follow), but it’s important to remember that both the microformats.org formats and RDFa have been around for several years and therefore have already established themselves in many implementations across the web.

The surge of articles which will surely be written about about HTML5′s “items” don’t mean that it’s time to blindly throw out microformats/RDFa (for a variety of reason I’m sure others will point out).  My reason is a purely pragmatic one — breadth and depth of support — it’s too early to chuck out microformats that already have support in favor of HTML5 microdata. Unfortunately, that may mean writing redundant code.

Below is an example of a “profile” I’ve been working on as a basic structure for contact information/profiles. It already used HTML5 tags and microformats and was awaiting some RDFa. When a coworker sent me the Dive into HTML5 article I spent some time at lunch adding HTML5 microdata and tested it in Google’s Rich Snippets Testing Tool.

I won’t go into exhaustive detail about every line. The sites I linked above give good introductions to microdata. I’ll just draw your attention to a few things I think are worth noting.

Semantic person in HTML5

I started with the new HTML5 figure tag. It designates a section of a document that contains multimedia with a caption. figure seems like a good fit to me because…

  1. Profiles tend to show a picture of a person which is effectively captioned by the name of the person.  The two are related in a way that figure alone communicates.
  2. Often profiles are embedded in ways that make the profile an independent part of the page that is supplementary to the page content.

So, figure jumped out at me for the reason it seems to fit semantically and for the reason it “feels” modular.

<figure class="vcard" id="vcard-lastfirst-idnum123" itemscope="itemscope" itemtype="http://www.data-vocabulary.org/Person/" title="Firstname Lastname">
  • To “activate” hCard I’ve added class="vcard",
  • And to add HTML5′s “item” functionality/microdata I’ve added itemscope and itemtype.
  • I’ve used the definitions in Google’s Data Vocabulary which is integrated into their Rich Snippets and can be written as a microformat, an HTML5 item, or RDFa.
  • I’ve added an id to remind myself to give the card a unique ID so that it can be easily referenced using the microformat include.
  • I’ve used a title attribute because I’ve noted it sometimes appears in accessibility plugins.  I don’t want to be redundant, but some plugins I’ve check out have seemed to ignore the header when labeling areas for navigation–even with WAI-ARIA (which I haven’t included in this sample anyway), so title is in.

Organization within Person

When you’re giving a person’s organization and title, that organization is another entity itself that you may want to give additional information about. All of the places I’ve tested so far support nested vcards, and Google’s Rich Snippet Tester appeared to do well with nested items.

...
<div class="org" itemprop="affiliation" title="Organization" itemscope="itemscope" itemtype="http://www.data-vocabulary.org/Organization/">
	<div class="vcard">
		<span class="organization-name fn" itemprop="name">Organization Name&</span>
		<div class="adr" itemprop="address" itemscope="itemscope" itemtype="http://data-vocabulary.org/Address/">
			<!-- Address -->&<span class="street-address" itemprop="street-address">6601 N Monroe&</span>
			<!-- City -->&<span class="locality" itemprop="locality">Tallahassee&</span>,
			<!-- State -->&<abbr class="region" itemprop="region" title="Florida">FL&</abbr>
			<!-- Zip -->&<abbr class="postal-code" itemprop="postal-code" title="32303-9329">32303&</abbr>
			<!-- Country -->&<abbr class="country-name" itemprop="country-name" title="United States">USA&</abbr>
			<!-- Lat/Lon (Metadata) -->
			<span class="geo" itemprop="geo" itemscope="itemscope" itemtype="http://data-vocabulary.org/Geo/">
				<abbr class="latitude" itemprop="latitude" title="60.6060606060">60.6060606060&</abbr>
				<abbr class="longitude" itemprop="longitude" title="-60.6060606060">-60.6060606060&</abbr>
			</span>
		</div> <!--/ .adr -->
	</div> <!--/ .vcard -->
	<span class="organization-unit">Unit&</span>
	<span class="title" itemprop="title">Job Title&</span>
</div> <!--/ .org -->
...

That’s a geo location nested within an address nested within an organization nested within a person. You start with the person and mention the organization as a name, then include the separate vcard for the organization. The organization has its own address and that address has its own geo code.

Telephone & E-mail

Google’s data vocabulary doesn’t specify telephone numbers for a person, only for organizations. It also lacks any reference to e-mail addresses anywhere. Since my test case is primarily for a person and the hCard microformat doesn’t have that problem I’ve used the pattern that works for hCard and incorrectly bolted Google’s data vocabulary on with HTML5′s microdata/item properties. It’s wrong for Google’s data vocabulary. I did it, but I’m thinking it’s probably best to leave it out and let the hCard microformat handle that part**.

With HTML5, microdata, and microformats

Download the current version of Microformats in Profiles & Contact Information here.  You can also see the use of HTML5 microdata + Google’s Review Data Vocabulary + hReview in there along with a few other things.  It’s still under development so I recommend you use the link to ensure you are looking at the most recent code. :-)