Simple Semantics With Microformats, Part 2

Emily P. Lewis | September 22, 2010


In Part 1 of this series, I covered what microformats are, their benefits and detailed two simple microformats, rel-tag and XFN:

  • Semantic markup is markup that describes content.
  • You can add even more meaning to your markup with microformats, which are basic markup patterns that narrowly describe today’s most common web content.
  • The data patterns in microformats are simply HTML attributes (most often rel and class) and values.
  • The semantic meaning microformats provides enables user agents, applications, computers and the like to parse, extract and transform microformatted content.
  • The rel-tag microformat is applied to tag links, such as those commonly seen with blog posts.
  • The XFN microformat is used to indicate online social relationships and aids in online identity consolidation.

In this Part 2, we’ll continue down the path of practical microformats with hCard, which is used to add semantics to contact information for people, organizations/companies and places.

hCard Roots

One of the goals of microformats is to use existing standards in order to encourage adoption and provide ease of implementation. This is why the foundation of microformats is HTML, a language well-known by most designers and developers.

The hCard specification is also based on another existing standard, vCard, for electronic business cards (.vcf). hCard uses a 1:1 representation of vCard, so that that web content published with hCard can be converted to vCards by machines and used in any vCard application or service.

hCard for Individuals

hCard is one of the most popular microformats today. Yahoo! Searchmonkey indicates there are over 2 billion instances of hCard on the web. And no surprise there, as hCard is the microformat for contact information … content found on just about every single web site out there.

Unlike rel-tag and XFN, which use the rel attribute, hCard relies on the class attribute for specifying values. Also, unlike rel-tag and XFN — which use a single attribute — hCard is a compound microformat, meaning it uses severalclass attributes and values to indicate the semantics of contact information.

Let’s take a simple example of contact information for an individual:

Emily Lewis

Web Designer

Albuquerque, NM 87106

What I recommend for implementing hCard (and all microformats) is to first focus on the content and then determine which class values are relevant. For this example:

Content hCard class Values
Root (required) vcard
Name (required) fn
Title title
Web site url
Address adr
  City   locality
  State   region
  Zip code   postal-code

Note the first value in this list, vcard. This is the required root value for hCard and it must be applied to the markup element that contains all of the contact information.

Next, mark up the content (using POSH, of course):

    <dt><a href="">Emily Lewis</a></dt>
    <dd>Web Designer</dd>
    <dd class="adr">Albuquerque, <abbr title="New Mexico">NM</abbr> 87106</dd>

Lastly, add the relevant class values to the markup, making sure to include the root vcard on the containing element:

<dl class="vcard">
    <dt class="fn"><a href="" class="url">Emily Lewis</a></dt>
    <dd class="title">Web Designer</dd>
    <dd class="adr"><span class="locality">Albuquerque</span>, <abbr title="New Mexico" class="region">NM</abbr> <span class="postal-code">87106</span></dd>

You may notice that in order to apply the locality and postal-code values, I needed to also add <span>tags to serve as hooks for those values:

<dd class="adr"><span class="locality">Albuquerque</span>, <abbr title="New Mexico" class="region">NM</abbr> <span class="postal-code">87106</span></dd>

This is simply a reality. Sometimes you have to add extra, non-semantic markup in order to achieve machine-readable semantics. Even as a lover of lean, semantic markup, I’m okay with this. The value of microformats far outweighs my need to keep my markup free of “unnecessary” elements.

Also, these are just a small sampling of the class values in hCard. If your contact information has more — photo, telephone number, email address, etc. — there are additional hCard values you can utilize. Reference the Microformats Wiki to get the full set or, better yet, pick up a copy of my book, Microformats Made Simple

hCard for Organizations

While the last example focuses on an individual, hCard also provides semantics for company or organization contact information. And the process is the same as it is for individuals’ information. Start with the content to identify which hCard class values are needed:

New Mexican Connection
208 Muriel Street Northeast
Albuquerque, NM 87123

This company example includes a bit more information than the individual example, including street address and phone number. The hCard values relevant for this content are:

Content hCard class Values
Root (required) vcard
Name (required) fn
Organization (required) org
Web site url
Telephone number tel
Address adr
  Street address   street-address
  City   locality
  State   region
  Zip code   postal-code

As with the first example, the root vcard is required, as is the fn value to indicate the name. Because we are dealing with a company, you’ll notice a new required value, org. This tells machines that the contact information is specific to a company or organization, rather than a person.

Now that you know what class values will be used, the next step is the semantic markup:

<h1><a href="">New Mexican Connection</a></h1>
<li>208 Muriel Street Northeast</li>
<li>Albuquerque, <abbr title="New Mexico">NM</abbr> 87123</li>

And, lastly, apply the hCard class values:

<div class="vcard">
<h1 class="fn org"><a href="" class="url">New Mexican Connection</a></h1>
<ul class="adr">
<li class="street-address">208 Muriel Street Northeast</li>
<li><span class="locality">Albuquerque</span>, <abbr title="New Mexico" class="region">NM</abbr> <span class="postal-code">87123</span></li>
<li class="tel">505-292-5493</li>

A few things to note about this example:

  • In order to apply the root vcard, I needed to add a containing element (<div>). Once again, another situation where extra, non-semantic markup provides a necessary hook to get machine-readable semantics.
  • The new org value to indicate this is an organization hCard is applied to the <h1> along with fn.  These two values should always be assigned to the same element when you are working with organization/company hCards.
  • Yes, you can use multiple class values with microformats. In this case, both fn and org are for indicating semantics, but you could also have class values for presentation. But, then again, you could save yourself time and simply use fn and/or org in your CSS.

Also, a note about phone numbers in hCard. The previous example lists a single phone number. By default, machines will parse the number and identify it as a “voice” number.

If you want to indicate the number is a different type, such as fax or cell, or you want to list several types of numbers, you use a class of type nested inside the element assigned class="tel":

<li class="tel"><span class="type">Work</span>: 505-292-5493</li>

Machines use the inner text for the type value, in this example, “work.” There are several accepted type values, the most common are:

  • Home
  • Work
  • Voice
  • Fax
  • Cell

And these values are case insensitive. For a complete list of telephone types, reference the Microformats Wiki or my book.

hCard for Places

The final type of contact information hCard can be applied to is that for named places. The syntax for named places is identical to that for organizational hCards, utilizing the org value alongside fn.

But let’s not get ahead of ourselves. Let’s first consider the content:

One of the best vacations I’ve ever had was a tour of Florence, Italy, when I saw the Il Duomo de Firenze (

Now, before we dive into the markup, I want to point out that this example is slightly different than the ones we’ve used previously. The content is in a “natural language” format. That is, it appears in the course of natural sentences, rather than being “chunked” as in the previous examples.

The reason why I’m using natural language for the place hCard is to demonstrate that you are not tied to any particular markup when publishing microformats. You can use any HTML your heart desires as the “hooks” for your microformats.

That said, both the microformats community and I strongly encourage valid POSH. If you are trying to enrich your content with microformats, don’t ignore your markup. Semantic, structural markup, too, enriches your content.

Okay, back to the example. Based on the content, the hCard class values we’ll use are:

Content hCard class Values
Root (required) vcard
Name (required) fn
Place (required) org
Web site url
Address adr
  City   locality
  Region   region
  Country   country-name

Next, apply markup:

<p>One of the best vacations I’ve ever had was a tour of Florence, Italy, when I saw the <a href="">Il Duomo di Firenze</a>.</p>

Finally, add the hCard class values:

<p class="vcard">One of the best vacations I’ve ever had was a tour of <span class="adr"><span class="locality">Florence</span>, <span class="country-name">Italy</span></span>,when I saw the <a href="" class="fn org url">Il Duomo di Firenze</a>.</p>

As with the other two hCards, there are several more class values you can use if it is relevant to your content. With named places, for example, you could also use geo, latitude and longitude, which indicate the geolocation for a place. Once again, I refer you to the Microformats Wiki or my bookfor further details.

hCard Benefits

Now that you know how to publish hCard, you may be wondering why. Like all microfomats, hCards offers some global benefits:

  • Minimal investment: Microformats are easy to learn, easy to implement and don’t require any special software or technologies.
  • Web standards: Microformats encourage the use of valid POSH.
  • Workflow efficiencies: Because microformats use a standard set of attribute values, teams can establish internal standards for class naming, as well as for markup patterns.

There are also some unique benefits hCard offers in terms of improving the user experience and discoverability.

Electronic Business Cards

The most powerful benefit of hCard is giving users the ability to download electronic business cards. Thanks to the semantics that provide machine-readability, there are tools available that extract contact information published with hCard and transform it into a .vcf file users can save to their address books.

One of my favorite machines for achieving these electronic business cards is Oomph, a jQuery-based (and browser-independent) toolkit that can be added to any site. If that site includes hCard, Oomph extracts the content, transforms it and provides users a range of options, including the ability to download the .vcf business card:

ffFigure 1: When Oomph detects hCard on a site, the jQuery overlay provides "contacts" options for users to export business card information to Yahoo!, Outlook, and Address Book.

A Bit More About Oomph

Oomph is unique among the dozens of microformats transformers available, and I can’t help but take a moment to describe it further.

As you can see from Figure 1 (which is the demo page), Oomph offers a range of functionality beyond the .vcf transformation of hCard. It provides map information not only for contacts, but also for events published with hCalendar. Events are transformed into downloadable .ics file for users’ calendar applications. And recently, they added functionality to detect and play media files marked up with hMedia.

While having a “dashboard” of microformat functionality is, in itself, impressive, the fact that Oomph is built on jQuery takes it to a new level in this standardista’s eyes. Because of its jQuery foundation, Oomph can be easily installed on any web site and the “dashboard” functionality is available on any browser with JavaScript enabled (although I’ve seen some reports of issues with IE8). Further, because it exists on the site itself, Oomph does not require users to install anything to access the functionality.

From my perspective, Oomph was one of the first (and, I believe, remains the only) microformat transformer that has this level of browser- and technology-independence. More developers should see this as a challenge to create even more tools with this flexibility and power.

Other hCard Transformers

Of course, Oomph isn’t the only option out there that provides hCard to .vcf transformation. You should also check out:

Google Rich Snippets

Another unique benefit hCard offers is better findability. Thanks to Google’s Rich Snippets initiative, content marked up with hCard (along with several other microformats and technologies) appears with at-a-glance summary information in Google’s search results:

Figure 2: By indexing hCards on the web, such as those used by LinkedIn, Google's Rich Snippets can better identify and display contact information in it's search results.

When searching for a person, hCard helps Google display rich snippets that allow users to distinguish between people with the same name.

By adding a few hCard classes to your markup, you help Google provide these informative search snippets. Google users, meanwhile, can find what they are searching for more easily. And this, in turn, helps you: if users can see useful and relevant information from the page, they are more likely to click through.

Authoring Resources

I hope that by this point, you are itching to start publishing hCard right away. Here are a few authoring tools and resources available to help you get started:

Coming in Part 3

You now have a solid understanding of the basics and benefits of hCard, as well as how to publish it. And if you checked out Part 1, you also know how to publish rel-tag and XFN. In part 3 of this series, you’ll learn the hCalendar microformat for event information.

Until then, here’s some additional reading I recommend:


About the Author

Emily Lewis is a freelance web designer of the standardista variety, which means she gets geeky about things like semantic markup andCSS, usability and accessibility. As part of her ongoing quest to spread the good word about standards, she writes about web design on her blog, A Blog Not Limited, and is the author of Microformats Made Simple and a contributing author for the HTML5 Cookbook. She’s also a guest writer for Web Standards magazine and MIX Online.

In addition to loving all things web, Emily is passionate about community building and knowledge sharing. She co-founded and co-manages Webuquerque, the New Mexico Adobe User Group for Web Professionals, and is a co-host of the The ExpressionEngine Podcast. Emily also speaks at conferences and events all over the country, including SXSW, MIX, In Control, Voices That Matter, New Mexico Technology Council, InterLab and the University of New Mexico.

Find Emily on: