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:
<div class="vcard">
-
<p class="fn n"><span class="given-name">Emily</span> <span class="additional-name">Paige</span> <span class="family-name">Lewis</span></p>
-
<p><a class="email" href="mailto:[email protected]">[email protected]</a></p>
-
<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>
-
<p class="nonVisual"><a href="http://www.ablognotlimited.com" rel="home me" class="url">A Blog Not Limited</a></p>
</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 (viasrc
). This property could also be applied to an<object>
element referencing the photo URL via thedata
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.)
Sub-Properties
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"):
<p><a class="email" href="mailto:[email protected]"><span class="type">pref</span>erred email</a></p>
<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.
<p class="tel"><span class="type">Work</span>(<span class="type">pref</span>erred): <span class="value">555-123-4567</span></p>
<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 addressclass="extended-address"
for my apartment numberclass="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:
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:
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:
<div id="creator" class="vcard">
-
<h3><a href="/about/" title="Learn more about Emily">The Coolest Person I Know</a></h3>
-
<a href="/about/" title="Learn more about Emily"><img src="/images/emilyLewisThumb.jpg" width="80" height="80" class="photo" alt="Emily Lewis" /></a>
-
<p>Yeah, that would be me: <a class="fn email" href="mailto:[email protected]">Emily Lewis</a>.</p>
-
<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>
-
<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>
-
<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>
</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, then
property can be implied if thefn
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 nameurl
property for web siterel
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:
<div class="vcard">
-
<p class="fn org">Big Ass Blow-Up Dolls</p>
-
<img src="logo.png" class="logo" width="69px" height="69px" alt="Big Ass Blow-Up Dolls" />
-
<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>
-
<ul>
-
<li class="tel"><span class="value">696-969-6969</span></li>
-
<li><a class="email" href="mailto:[email protected]">Email Us</a></li>
-
<li><a class="url" href="http://www.babud.com/">Visit Our Web Site</a></li>
-
</ul>
</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 theorg
property. And with companies/organizations, you never use then
property. - Rather than
photo
for the<img />
, the associated image is marked up with thelogo
property.
Places
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
andlongitude
. - 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.
Semantics
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:
Firefox
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:
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:
Tails Export 0.3.5 is another Firefox add-on that leverages hCard information for export into address book programs:
Safari
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.
Bookmarklets
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:
There are other hCard bookmarklets available as well.
Search
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:
- Google has added hCard microformats to its Google Maps.
- Technorati Microformats Search searches for hCard and other microformats, including hCalendar and hReview.
- Yahoo! Local marks up its results with hCard, as well as hCalendar and hReview.
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
andurl
in addition tofn
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.
♥ Share the Love