A Blog Not Limited

to web design, standards & semantics

Getting Semantic With Microformats, Part 3: hCard

Sep 22, 2008

Published in


I began this series by detailing the microformats for link-based relationships using the rel attribute in Part 1. I then followed up in Part 2 with a discussion about extending the rel attribute with XFN values to connote social relationships on the web.

Both XFN and the rel-based microformats are relatively simple, requiring only the addition of the rel attribute to links (<a>) and the proper value(s) to provide semantic context.

Now it is time to take this microformats discussion to a more detailed level with the hCard microformat, which adds semantics and structure to web content about people, organizations, companies and places.

(Get comfortable, this is a long one.)

Origins: vCard

vCard is a standard for electronic business cards, which are commonly attached to emails as files with the extension ".vcf". Just like traditional business cards, vCards contain name and contact information.

hCard was introduced as a standard format for allowing web authors to include vCard information in their web pages.

hCard uses a 1:1 representation of vCard. This means that web content marked up with the hCard format can be converted to vCards by spiders and other aggregators, and can be used in any vCard application or service.

People, Organizations, Companies & Places

The hCard microformat represents people, organizations, companies and places — most commonly in terms of address/contact information, including but not limited to:

  • Formatted/structured name
  • Mailing/delivery address
  • Email address
  • Telephone number(s)
  • Photograph

Of all the information that can be included in hCard, the only required information is the formatted name. Everything else is optional.

And, as with all microformats, hCard uses existing markup and attributes to specify this address/contact information, in particular various class values, which are referred to as "properties" and "sub-properties."

A Person, Namely Me

One of the first hCard implementations on A Blog Not Limited is for my personal contact information on my About page:

  1. <div class="vcard">
  2.       <p class="fn n"><span class="given-name">Emily</span> <span class="additional-name">Paige</span> <span class="family-name">Lewis</span></p>
  3.       <p><a class="email" href="mailto:[email protected]">[email protected]</a></p>
  4.       <p class="adr"><span class="locality">Albuquerque</span>, <abbr class="region" title="New Mexico">NM</abbr> <span class="postal-code">87106</span> <acronym class="country-name" title="United States of America">USA</acronym></p>
  5.       <p class="nonVisual"><a href="http://www.ablognotlimited.com" rel="home me" class="url">A Blog Not Limited</a></p>
  6. </div>

The first thing to note about the above example is that all of the markup and content is contained by a <div> assigned class="vcard".

The containing element could be anything (<p>, <ul>, <span>, etc.), as long as it is valid markup and, preferably, semantic.

What is essential is the class="vcard".

"But the microformat is called hCard … what's with the vcard property?" you may ask.

Well, this is because of the 1:1 respresentation to vCard. All of the specified hCard properties (class values) are based on vCard property type names.

Accept it and move on.

Personal Identity Information

Breaking down the example into its various properties, let's start with those that personally identify me, such as my name. You can see that my name information is contained by <p class="fn n">:

<p class="fn n"><span class="given-name">Emily</span> <span class="additional-name">Paige</span> <span class="family-name">Lewis</span></p>

The fn property indicates that the content contained within is a string corresponding to the name of the person, as you might see on a nameplate. As I mentioned, this is a required property in the hCard microformat.

The n property indicates that the content within contains parts of a person's name, such as the first, middle and last names.

While the n property is required by the specification, it can be implied (that is, not specified), if the content contained by the fn property is exactly two words. The Microformats wiki explains this implied optimization in detail.

There are a few other identification properties I could include if I were so inclined:

  • class="nickname" indicates a person's nickname/handle, and is applied to an element containing the text of that nickname.
  • class="photo" indicates a photo associated with a person, and is applied to an <img /> element referencing the URL of the photo (via src). This property could also be applied to an <object> element referencing the photo URL via the data attribute (though this is, to me, a non-semantic option).
  • class="bday" indicates a person's date of birth, and is applied to an element containing that date information.
Sidebar: Dates

Update: 06/02/2009

The datetime design pattern is now deprecated in favor of the value class pattern. See part 8 of this series for more on this new pattern.

I should mention that when it comes to date information, it is often marked up with both human– and machine–readable information. This is called the datetime design pattern.

Without going into too much detail (because I will be covering this extensively with the hCalendar microformat in Part 4 of this series), here is an example of how date information is commonly referenced in the various microformats:

<abbr class="bday" title="1974-09-04">September 4, 1974</abbr>

Notice what is contained by the <abbr> is human–readable date information, while the title value is machine–readable date information.

The use of the <abbr> element for date information (the abbr design pattern), however, has raised some accessibility concerns.

Again I will be covering this in further detail in Part 4, but what has been proposed to get around these concerns is to use a <span> element with a title value rather than <abbr>. (I also will be addressing accessibility issues in greater depth at the conclusion of this series.)


So, getting back to the example on my About page …

Many hCard properties also have sub-properties to provide even more context. In my example, I mark up the content within <p class="fn n"> with <span>s referencing sub-properties:

<p class="fn n"><span class="given-name">Emily</span> <span class="additional-name">Paige</span> <span class="family-name">Lewis</span></p>

  • My first name is indicated by class="given-name".
  • My middle name is indicated by class="additional-name".
  • My last name is indicated by the class="family-name".

Of these three sub-properties, given-name and family-name can only be used once per vcard, whereas the additional-name sub-property can be used multiple times.

And there are two additional sub-properties I could've included:

  • class="honorific-prefix" indicates name prefixes (i.e. Mr., Dr.), and is applied to an element containing the text of that prefix.
  • class="honorific-suffix" indicates name suffixes (i.e. MD, PhD), and is applied to an element containing the text of that suffix.

Like additional-name, these two sub-properties can also be used multiple times.

Email & Phone Information

The next part of the example is my email address in <a class="email">:

<p><a class="email" href="mailto:[email protected]">[email protected]</a></p>

Assigning the email property to my link (<a>) indicates that the href value is my email address. The content contained by the <a> could be anything. I simply chose to display the actual value of my email address.

The email property can be used multiple times. In those cases, the sub-property type can be added to indicate which of the multiple emails is preferred ("pref"):

  1. <p><a class="email" href="mailto:[email protected]"><span class="type">pref</span>erred email</a></p>
  2. <p><a class="email" href="mailto:[email protected]">alternate email</a></p>

I could also include another property, tel, which indicates a person's phone number (via the value sub-property). The tel property has a type sub-property to indicate the type of number (i.e. home, work, fax):

<p class="tel"><span class="type">Work</span>: <span class="value">555-123-4567</span></p>

The type sub-property is entirely optional. If you choose to omit it, the default value is "voice."

The tel property can be used multiple times, as can type. The type sub-property can also indicate "pref" to show it is the preferred number.

  1. <p class="tel"><span class="type">Work</span>(<span class="type">pref</span>erred): <span class="value">555-123-4567</span></p>
  2. <p class="tel"><span class="type">Home</span>: <span class="value">555-789-0123</span></p>

Finally, the value sub-property can be implied. If a type is specified but no value is specified, then everything other than type in the tel property is considered the value.

Address Information

The next part of the example includes my address contained by a <p class="adr">:

<p class="adr"><span class="locality">Albuquerque</span>, <abbr class="region" title="New Mexico">NM</abbr> <span class="postal-code">87106</span> <acronym class="country-name" title="United States of America">USA</acronym></p>

The adr property indicates the parts of an address, which I delineate with <span>s assigned the various address sub-properties:

  • City is indicated by class="locality".
  • State is indicated by class="region". This sub-property would also be used for provinces.
  • ZIP code is indicated by class="postal-code".
  • Country is indicated by class="country-name".

Note that for my country-name, I used the <acronym> element for a shorter reference to my country, with the full name included in the title. I could've just as easily written out the full name and bypassed <acronym> entirely. Just a matter of preference (although I strongly encourage semantic brevity).

For even greater address detail, I could've also included:

  • class="street-address" for my street address
  • class="extended-address" for my apartment number
  • class="type" to indicate the type of address (i.e. home, work)
Sidebar: address

But wait! What about semantics? Why not use the <address> element as the container for the address information, rather than a <p>?

Actually, it wasn't until I was writing this article and doing the research that I discovered that I have been improperly using <address> for years. I had always thought that it was literally for physical addresses, such as in this very example.

I was wrong.

According to the W3C, the <address> element is:

… used by authors to supply contact information for a document or a major part of a document such as a form.

So, in some instances, it could be an appropriate container for contact information … if that contact information is for the document owner.

For these examples, I'm forgoing the use of <address> since it really depends on the situation.

Web Site Information

The last part of my example contains my blog URL in <a class="url">:

<p class="nonVisual"><a href="http://www.ablognotlimited.com" rel="home me" class="url">A Blog Not Limited</a></p>

The url property indicates that the link (<a>) destination (href) is to a web site associated with me. Though I'm referencing my blog, this could also be a link to my design portfolio or any other URLs associated with me.

A few things to note about this final part of the example:

  • In keeping with my commitment to the rel-based microformats, I've also made sure to include rel="home me". See how easy it is to combine microformats?
  • The link is contained by <p class="nonVisual">, which is just a paragraph I've assigned a custom class to suppress the display of the information because I didn't think it was necessary to show in this particular situation. Regardless, it has no bearing on the hCard microformat.
Final Product

After that exhaustive explanation of the markup, here's how it looks:

Emily's vCard

And because hCard just uses standard XHTML, it can be styled any way your heart desires.

If you haven't figured it out already, I have a rather minimalist aesthetic, so I went with virtually no styling other than the use of class="nonVisual" to suppress the display of some content (note that this is a personal choice I made for this particular situation; I do not encourage rampant use of "hiding" content, particularly for black hat SEO techniques).

But, as an example of what you could do, Chris Coyier recently posted a Microformats Business Card, which uses the core hCard markup with some very nice CSS to mimic a traditional print business card.

The possibilities are only limited to your CSS skills.

Add to Address Book?

You see in my example that immediately following my hCard content, I offer a link to "Add to Your Address Book." This is just a link to the vCard file that can be downloaded and added to an address book program.

You could easily offer a direct link to the .vcf that you create and keep on your server, or you can take advantage of Technorati's Contacts Feeds Service.

Using Technorati's technology, you simply prepend the URL of the page where your hCard microformat resides with http://feeds.technorati.com/contacts/ and t,hen use the resulting URL as the href value for your link (<a>).

<a href="http://feeds.technorati.com/contact/http://www.ablognotlimited.com/about/" title="Download vCard">Add to Address Book</a>

When a user selects that link, the vCard is dynamically created and they can download it:

Downloading Emily's vCard

Some Rules & A Reminder

Now that I've gone over my first hCard example, it is necessary to point out some rules:

  • Property and sub-property names are case-sensitive.
  • The vcard "root" can't be combined with any of its properties. Therefore, class="vcard fn" is invalid.
  • Properties can't be combined with sub-properties. Therefore, class="tel value" is invalid.

That's not so bad is it? I mean, c'mon, microformats are standards. Of course there are going to be a few rules.

And don't forget: It isn't about the markup, per se, when it comes to microformats. It is about the class values and various markup attributes — properties and sub-properties.

You can pretty much use whatever (X)HTML elements you want and still have the microformats be valid if you are properly assigning the properties and sub-properties.

Of course, if you are going to bother embracing the semantics of microformats, you should also embrace semantic markup.

Let's Not Forget the Profile

Update: 04/21/2010

Recently, the microformats community completed updates to the profile URIs for all microformats. The correct values have been updated in this article. See my Microformats Profile URIs Updated post for further details.

Just as I mentioned with XFN, it is recommended to include the hCard profile in the <head> of web pages that include the microformat:

<head profile="http://purl.org/uF/hCard/1.0/http://microformats.org/profile/hcard">

The W3C allows multiple profile values, separated by white space, so you can have both profiles for hCard and XFN present:

<head profile="http://gmpg.org/xfn/11 http://purl.org/uF/hCard/1.0/http://microformats.org/profile/hcard">

Update: 09/30/2008

I recently discovered there is a combined profile for all non-draft microformats that can be used, rather than listing multiple profiles in a document <head>:

<head profile="http://purl.org/uF/2008/03/http://microformats.org/profile/specs">

Also, if you are using a single microformat on a page, you can use this combined profile if that microformat is non-draft. However, for draft microformats, you need to specify the profile for that particular microformat.

Thus far, all of the microformats I've discussed in this series (with the exception of rel-home) are non-draft.

Again, as I already mentioned with regard to XFN, I maintain my <head> in a global include, so it is referenced across the whole of A Blog Not Limited. However, as it turns out, this is required, because I use the hCard microformat on every page of my site (in the footer).

Which segues very nicely into the next part of this article …

Natural Language hCard

A while back, I came across a great article from the brilliant Jeremy Keith, who suggests using hCard in natural language.

Essentially, he proposes applying hCard properties and sub-properties to contact information (i.e. name, web site, email) that appears in the course of natural sentences, as opposed to "chunking" a person's contact information as in my first example.

The concept is so simple and really opens up the opportunities for using hCard, so of course I decided to use it on A Blog Not Limited in my footer where I have a little blurb about myself:

  1. <div id="creator" class="vcard">
  2.       <h3><a href="/about/" title="Learn more about Emily">The Coolest Person I Know</a></h3>
  3.       <a href="/about/" title="Learn more about Emily"><img src="/images/emilyLewisThumb.jpg" width="80" height="80" class="photo" alt="Emily Lewis" /></a>
  4.       <p>Yeah, that would be me: <a class="fn email" href="mailto:[email protected]">Emily Lewis</a>.</p>
  5.       <p>I'm a <span class="title">web designer</span> living in <span class="adr"><span class="locality">Albuquerque</span>, <span class="region">New Mexico</span><span class="postal-code nonVisual"> 87106 </span><acronym class="country-name nonVisual" title="United States of America">USA</acronym></span>, and I'm a "standardista."</p>
  6.       <p>I specialize in hand-coding semantic <acronym title="eXtensible Hypertext Markup Language">(X)HTML</acronym> and <acronym title="Cascading StyleSheets">CSS</acronym>, designing accessible web sites, and writing and optimizing web content.</p>
  7.       <p><a href="http://www.ablognotlimited.com" rel="home me" class="url">A Blog Not Limited</a> is my personal blog where I pontificate about web design, web standards, semantics and whatever else strikes my fancy.</p>
  8. </div>
The Differences

Other than the fact that the hCard content in this second example is "inline" with non-hCard content, there are a few slight differences in the hCard properties and sub-properties used:

  • I only reference my first and last name in this example, so I only use class="fn". Remember, the n property can be implied if the fn content is exactly two words.
  • I include my job title in the description, so I add class="title", which is one of several properties that provide information about a person's organizational affiliation. This property indicates my job title.
  • I include a photo of myself, so I add class="photo" to the <img />.

However, these differences from the first example have nothing to do with the fact that I'm using the hCard in natural language. These were just the appropriate values to use with the content in this particular instance.

Combining hCard & XFN

As I mentioned, this concept of hCard in natural language provides so many more contexts in which hCard can be used. I've already applied it to information about me, but I regularly refer to friends and colleagues in my articles … it makes perfect sense to mark up those references with hCard.

And it doesn't even matter that I'm already marking up those references with XFN values. One of the best things about microformats is that they can be easily combined.

Depending on the context of the reference, I use slightly different markup.

For situations where I'm referencing an article/post someone has written (such as the above reference to Jeremy Keith), I use <cite> as my vcard container:

<p> … the brilliant <cite class="vcard"><a href="http://adactio.com" rel="muse colleague" class="url fn" title="Link opens off this site">Jeremy Keith</a></cite>, who suggests using <a href="http://adactio.com/journal/1122/" title="Link opens off this site">hCard in natural language</a>.</p>

And in situations where I'm simply referencing the person, I use <span> as my vcard container:

<span class="vcard"><a href="http://www.jenschwedler.com/" title="Link opens off this site" class="url fn" rel="met colleague co-worker friend">Jen Schwedler</a></span>

Finally, if I only reference the person by their first name, I use <abbr> for the formatted name container with the full name as the title value:

<span class="vcard"><abbr class="fn" title="Ian Pitts"><a href="http://www.iso-100.com/" title="Link opens off this site" class="url" rel="met colleague co-worker friend">Ian</a></abbr></span>

In all of these examples, however, the markup differences simply reflect my preferred semantics. The hCard and XFN microformats are the same:

  • fn property for name
  • url property for web site
  • rel values as appropriate

And if I had additional information about these folks (such as job title, email, etc.) I would similarly mark up that content with the appropriate properties/sub-properties.

Organizations & Companies

While I've yet to encounter a situation where I needed to use hCard to describe a company or an organization on this blog, I did want to provide an example of how it could be implemented:

  1. <div class="vcard">
  2.       <p class="fn org">Big Ass Blow-Up Dolls</p>
  3.       <img src="logo.png" class="logo" width="69px" height="69px" alt="Big Ass Blow-Up Dolls" />
  4.       <p class="adr"><span class="street-address">6969 Happiness Avenue</span>, <span class="locality">Los Angeles</span>, <abbr class="region" title="California">CA</abbr> <span class="postal-code">69069</span></p>
  5.       <ul>
  6.             <li class="tel"><span class="value">696-969-6969</span></li>
  7.             <li><a class="email" href="mailto:[email protected]">Email Us</a></li>
  8.             <li><a class="url" href="http://www.babud.com/">Visit Our Web Site</a></li>
  9.       </ul>
  10. </div>

As you can see, hCard for organizations/companies is essentially the same as it is for individuals. The main differences are:

  • In addition to the fn property for the name, organization name is also assigned the org property. And with companies/organizations, you never use the n property.
  • Rather than photo for the <img />, the associated image is marked up with the logo property.


What I've detailed for companies and organizations would be the same approach for places. You would simply reference the name of the place with the fn org properties and apply all address information as I've demonstrated above.

Here's a natural language example of hCard for a place:

<p class="vcard">During my visit to <span class="locality">Altanta</span>, <abbr title="Georgia" class="region">GA</abbr>, I plan to check out <span class="fn org">Centennial Olympic Park</span>.</p>

There are a few location-specific hCard properties that are particularly useful for places (though they aren't limited to places):

  • The geo property specifies global position using two sub-properties, latitude and longitude.
  • The latitude sub-property specifies a decimal value that indicates vertical position in relation to the equator.
  • The longitute sub-property specifies a decimal value that indicates horizontal position in relation to the prime meridian.

Let's Talk Benefits

So now that I've covered several examples of hCard, it is time to go over the benefits.


You knew it was coming. I've said it before and I'll say it again:

The use of microformats adds structure and meaning to web content, making it both human– and machine–readable. And all with existing standards for markup and data.

This also encourages the broader concept of web standards, which benefits everyone.

Share Contact Information

By using hCard to mark up contact information, you automatically make it possible for that information to be converted into a downloadable vCard, which can then be used by programs such as Microsoft's Outlook and Apple's Address Book.

You can use the Technorati contacts feed service I mentioned previously, or you can create your own and host it on your server for downloading.

Plus there are several browser add-ons/extensions that automatically export hCard information into vCards:


Operator 0.9.3 recognizes hCard content and gives users an option to export the information as a vCard for use by their preferred address book program:

Firefox Operator add-on with hCard vCard imported into Address Book

Also, you can see in the list of options in the screenshot, Operator uses the hCard information to search across other web sites, including Google Maps:

Google Maps search of hCard

Tails Export 0.3.5 is another Firefox add-on that leverages hCard information for export into address book programs:

Firefox Tails Export add-on with hCard

Safari Microformats plugin is useful for you Safari folks to identify the hCard microformats on a web page and save to your address book.

I'm not an avid Safari user, and the install for this plug-in was far too clunky for me … so I didn't install it and can't provide you a screenshot.


The concept behind the aforementioned Safari plug-in has been implemented in a browser-independent microformats bookmarklet, and I can confirm it is quite nice:

Microformats bookmarklet with hCard

There are other hCard bookmarklets available as well.


Web content marked up with microformats naturally has more meaning. This could help search engines better evaluate the content you provide and, perhaps, boost your search engine results ranking.

There are never any guarantees when it comes to search, but quality content in context is always a good start.

Beyond search results, many of the search engines themselves are implementing hCard in their own applications and services:

Social Networks

Social networking sites are using hCard microformats to mark up profile pages with users' contact information, as well as users' contacts/friends/followers:

  • Twitter applies hCard to profile pages, as well as on both following and follower lists.
  • ClaimID applies hCard on users' public profiles.
  • Last.fm applies hCard to profiles, which includes photo and url in addition to fn

And these are just a few. See the full list of services that are using hCard.

Tools to Make it Easier

I would be remiss if I didn't point you in the direction of some useful tools that can help you implement hCard much easier than hand-coding and remembering all the values (though that's the way I like it):

  • hCard creator is a simple form that generates an hCard from submitted information.
  • hCard microformat validator lets you submit a URL with hCard content, and then validates the properties and sub-properties.
  • There is an hCard cheatsheet for quick reference to the properties and sub-properties.

There Is So Much More

I've gone into some very specific detail about the hCard microformat. But there's so much more I didn't even mention.

I strongly encourage you to take some time and read up on all of the available properties and sub-properties of the hCard microformat, as well as see some of the examples of hCard in the wild.

Coming in Part 4

While this was a long article (which says a lot considering my normal tendency toward verbosity), I hope it was interesting and at least minimally useful to you.

Getting Semantic With Microformats, Part 4 will cover the hCalendar microformat.

Stay tuned …

Update: 10/18/2008

Christophe Ducamp has translated this article in French: Parvenir à la Sémantique avec les Microformats, 3ème partie – hCard.

Unfortunately, I don't read French, so I can't attest to the translation. But in the spirit of spreading the good word about microformats, I'm going to promote the translation and hope it is accurate. The way I see it, the more people who know about microformats, the better.

Update: 11/04/2008

Jan Sládek has translated this article in Czech: Kódujme sémanticky s mikroformáty: 3. část - hCard.

I don't read Czech either, so I can't speak for the translation. But the intention is good, so I'm promoting it.

Update: 12/07/2008

Jia Mi has translated this article in Chinese: 使用微格式来丰富网站语义: hCard.

HTML5 Cookbook

Interested in HTML5?
Get the Cookbook!

I was a contributing author for HTML5 Cookbook, available for sale on Amazon! Get yours now! (I hear chapters 1, 4 and 5 are particularly good.)

P.S. Don't forget my book Microformats Made Simple is still for sale!


Share the Love

Sarven Capadisli's Gravatar

Sarven Capadisli opines:


It is nice that you went into all the detail for your readers. Here are a few points I wanted to mention about your article:

“Notice what is contained by the abbr is human–readable date information, while the title value is machine–readable date information.”

This is misleading. YYYY-MM-DD format is arguably more human-readable (not to mention that it is ISO 8601), in other words *accessible* then “Eylul 4, 1974”. Do you see why? Similarly, the information in title is not originally meant to target machines. title is used for advisory text as per W3C spec.

Using address as part of the representative hCard on the page is perfectly fine if it also happens to be (which is common to majority of the cases) that the contact information for the document is a physical/tangible address. See address for document’s contact information.

Doing things like class=“nonVisual” misses an important part of the microformats vision: to mark visible data. If you are hiding information (similar to meta-data) it becomes stale, unreliable or verifiable.

Emily's Gravatar

Emily responds:


@Sarven - Thanks for the comment.

Good point about the machine-readable date information. Perhaps my example isn’t a good one to demonstrate the machine-readability aspect, yet that is the spirit of the microformat. Not to mention most vCard applications (machines) recognize it. Further, the ISO8601 profile is what is currently recommended by the Microformats wiki when using the datetime design pattern. It appears they are considering other formats, as they address the accessibility issues.

Which brings us to your point about the use of <abbr> for the date. And you are completely correct, which is why I mentioned the WaSP’s article about this particular accessibility problem and one of the the proposed alternatives (using <span>). At present, however, this issue is still under debate. It will be interesting to see how the Microformats community resolves it.

Regarding the use of address, I’m going to disagree with you slightly there. Yes, it could be used, perhaps, in the instance of my first example since I am the document owner. Yet it really isn’t meant for a physical address per se. As I understand the spec, it is used to contain the name and email (or URL) for document author(s). For my purposes, I’m forgoing the use of it in my examples per my understanding of the spec.

Finally, my choice to suppress the visual display of my web URL is a personal choice. Generally speaking, I don’t encourage the use of “hiding” content, particularly for black hat SEO techniques. However, in this example, it is simply my preference to provide the URL information for vCard export, but not repeat its visual display on this particular page. And I disagree about your point that by “hiding” it, it becomes stale, unverifiable or unreliable. But I’m happy to just agree to disagree on that.

Thank you so much for adding to the discussion. I appreciate your input and obvious passion for standards and microformats.

Ian Pitts's Gravatar

Ian Pitts opines:


I’m with Emily on the idea of hiding a link to the current site in a vCard. It’s generally bad form to link back to the current page… and since she’s using the hCard in the footer of every page on the site, having a link back to the current site is a bit over the top.

Harald Steindl's Gravatar

Harald Steindl opines:


Best Article on this subject ever! Thanks a lot!

Matt Haltom's Gravatar

Matt Haltom opines:


Emily great jog explaining Microformats & the hcard.  This was the best post I’ve found that really provides some solid examples of use.  I may even have to snag your book now… lol

Thanks a ton!

Toby's Gravatar

Toby opines:


Hi emily, Have been wondering how tantek (tantek.com) manages to get the vcard that downloads via h2vx to have two seperate urls, his twitter for personal and his identi.ca for business. Do you know is this feat able to be accomplished within the uF spec or some other magicry? currently my page’s url appears as personal and my pages’s and the linkedIn url appear as one link in business url… not ideal…. Thanks

Emily's Gravatar

Emily responds:


@Toby - I took a peek at his source code, and he has class=“url” assigned to all of his rel=“me” links in a single hCard. No magic there. And I looked at your source code ... same thing.

I don’t really know how H2XV works (I’m a front-end developer), but I’m taking a wild stab in the dark that perhaps because your hCard is nested in hResume H2VX is making an assumption that the URLs are work related? This is just a guess, though.

What I do know is that Tantek is very approachable and I’m sure if you contacted him (Twitter is probably your best bet) he could tell you.

Do let me know what you find out :)

Toby's Gravatar

Toby opines:


okey dokey will try Tantek’s twitter, am thinking its some ionner working of h2xv that he’s able totake advantage of with intimate knowledge of it, will report back if I find out.

Thanks for the help[ :)

Dale of SEO Grader's Gravatar

Dale of SEO Grader opines:


What other common applications support this use of semantic vCards?

Emily's Gravatar

Emily responds:


@Dale - In addition to all hCard parsers, extractors and transformers mentioned in this article, you can check out the Microformats Wiki for more. Also, since the writing of this article, Google has launched Rich Snippets, which utilizes hCard.

Deri's Gravatar

Deri opines:


I read your post and it realy help me. It’s the best to be found in the web - In fact I am so excited by your writing and didactic style and the subject-matter itself, that I immediately bought the book.

Commenting is not available in this channel entry.

The Coolest Person I Know

Emily Lewis

Yeah, that would be me: .

I'm a freelance web designer of the standardista variety, which means I get excited about things like valid POSH, microformats and accessibility. I ply my trade from my one-person design studio in Albuquerque, New Mexico 87106 USA.

A Blog Not Limited is my personal blog where I pontificate about web design, web standards, semantics and whatever else strikes my fancy. Head on over to Emily Lewis Design if you'd like to see my work or, even better, hire me.


I Tweet, Therefore I Am

Follow @emilylewis on Twitter!