Chapter 6. Defining People, Organizations and Places: hCard

The web is filled with oodles of content—about anything and everything. But one of the most common types of content that you can find on virtually every site is that which describes people, organizations, and even places.

Most often this content is in the form of contact information, such as a company’s address and phone number. And it is for this type of content that the hCard microformat was developed.

What Is hCard?

hCard, which I introduced by way of example in Chapter 1, is a formal microformat specification that you apply to contact information for people, places, and organizations and companies, including the following:

• Names

• Addresses

• Phone numbers

• Email addresses

• Logos

• Birthdays

Electronic business cards

hCard was developed based on vCard, the standard for electronic business cards (.vcf) that are used to populate electronic address books, including Microsoft Outlook and Apple’s Address Book.

In fact, hCard is based on a 1:1 representation of standard vCard properties and values, so every class name in hCard corresponds to a vCard property. This mapping helps machines extract hCard information from a web page and transform it into a .vcf that users can then add to their electronic address book. With hCard, users don’t have to enter new contacts manually, they can just import .vcfs constructed from web pages with hCard.

There are a bunch of tools that do this hCard-to-vCard conversion, such as Technorati’s Contacts Feed Service (Figure 6.1), which extracts hCard content from a submitted URL and generates a downloadable .vcf.

Figure 6.1 Technorati’s Contacts Feed Service

You can even let users download the .vcf directly from your site by providing a link to the page containing hCard and prepending the href value with the Technorati’s Contact Feeds URL:

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

When users select this link, the hCard is transformed into a .vcf, and users can download it directly to their computer (Figure 6.2). And the service recognizes multiple hCards on a page (such as you might find associated with a blogroll) and generates .vcfs for each.

Figure 6.2 Download prompt for .vcf from hCard

There are also some add-ons for Firefox that provide .vcf export from hCard information, including Tails Export (Figure 6.3 on the next page) and Operator. These, too, can identify multiple hCards and generate individual .vcfs.

Figure 6.3 The Tails Export 0.3.5 add-on for Mozilla Firefox identifies multiple hCards and provides .vcf export options for each.

One of the nice features of the Operator add-on is that it gives users even more functionality than an electronic business card. Operator also lets users search for hCard contacts in Google Maps, Yahoo! Maps, and MapQuest, and provides a direct import into Yahoo! Contacts (Figure 6.4).

Figure 6.4 The Operator 0.9.3 Firefox add-on provides search options for hCard, as well as electronic business card download.

But these tools aren’t limited to Firefox. Left Logic’s bookmarklet (http://leftlogic.com/lounge/articles/microformats_bookmarklet/) works in Apple Safari, Microsoft Internet Explorer (6 and 7), and Firefox. Like any bookmarklet, you drag it to your browser’s bookmark toolbar and, when you are on a page with hCard, you select the bookmarklet. It then generates a modal dialog displaying all hCards and providing links to export each into .vcfs (Figure 6.5).

Figure 6.5 Microformats bookmarklet provides hCard-to-vCard conversion on any browser.

Also, the Oomph Microformats Toolkit provides a browser-independent microformat detector via a jQuery overlay that you add to your website. Once the jQuery is in place, Oomph detects hCard (as well as hCalendar) on the page and displays a glowing icon in the upper-left corner that users can select to see hCard detail and access a variety of search and export options (Figure 6.6).

Figure 6.6 Oomph jQuery overlay displays hCard details and provides both .vcf export and search options.

Oomph is a giant leap forward in furthering the consumption of micro-formats by people who don’t even know what they are. Users don’t have to have a special browser or add-on. The site owner simply makes sure the jQuery overlay is in place, and Oomph instantly provides users with information and tools to make the most of hCard content.

Wide adoption

hCard is one of the more commonly used microformats today. This is primarily because, as I mentioned at the outset, contact information is virtually everywhere on the web. But I also think the wide range of tools to help users consume hCard information has encouraged its widespread use:

• Both Google Maps and Yahoo! Local mark up results with hCard.

• Google Profiles are published with hCard.

• Yahoo! Placemaker extracts adr and geo (hCard properties) content from web pages to help with geographic discovery and aggregation.

• Social networks Twitter, Facebook, and Last.fm apply hCard to their users’ profile pages; Twitter even uses hCard for following and follower lists.

• Dozens of other popular online services provide hCard profiles, including Flickr, Cork’d, LinkedIn, Upcoming, Vimeo, Plaxo, Digg, ClaimID, Technorati, and many, many others. As a result, hCard is the most widely adopted social network profile format on the web.

• Hundreds (maybe thousands or even hundreds of thousands) of blogs and personal and corporate websites mark up their contact information with hCard.

Search and SEO

As hCard has grown in popularity and use, its benefits have grown beyond electronic business cards into search. Like all microformats, hCard provides a standardized way to add meaning (particularly for machines) to content.

This is well suited for search, as search engines can more easily identify specific types of content via the use of those standard class values. With hCard, for example, the class values tell search engines which bit of content is the person’s or organization’s name, address, phone number, and more.

Currently, there are two microformat-specific search engines:

• Technorati’s Microformats Search (http://kitchen.technorati.com/search/)

• Virel (http://virel.de/)

These engines index submitted sites for microformats (hCard, hCalendar, and hReview) and generate results about contacts, events, and reviews. These results are published using microformats, enabling users to download, for example, .vcf from search results about a person.

For many years, major search engines like Yahoo! and Google were simply publishing their search results with hCard (and other microformats). They weren’t consuming hCard in their spidering algorithms.

Until now.

Supporting my theory that “if you build it, they will come,” Google developed Rich Snippets, a feature that indexes hCard- and hReview-microformatted content to provide summary information (snippets) in search results.

Since we’re talking about hCard, let’s focus on that for now. With Rich Snippets, users who search for people in Google will receive results with additional information (a Rich Snippet) that can help them distinguish between people with, perhaps, the same name.

More context leads to more meaningful search results and, potentially, more click-throughs. And, particularly for businesses, more click-through can mean more profit.

All content authors need to do to take advantage of Google’s Rich Snippets is mark up their content with hCard. That’s it. Google takes it from there.

As of this writing, Rich Snippets is still being rolled out gradually. But the simple fact that Google is now consuming microformats (rather than just publishing them) signals an important shift toward structure and markup with meaning—the core of microformats.

Google isn’t the only major search player that sees the benefit of microformats to support search results. Yahoo! SearchMonkey is an open search platform that has supported numerous microformats, such as hCard, since early 2008. And Yahoo! Search uses microformats to provide more meaningful and visually appealing search results.

These latest developments in search demonstrate the power and simplicity of microformats. Search engines recognize the value of structured data so that they can give their users more relevant search results. And because microformats are so simple to implement, any content author can get in the game.

If you haven’t yet joined the Microformats Are Way F’n’ Cool Club by now, these new search benefits leave you no excuse. How can you argue against adding a few class values (and maybe a bit of markup) to get better search results?

Profile

Once again, you want to start your hCard journey with the profile in your document <head>:

<head profile="http://microformats.org/profile/hcard">

As I mentioned back in Chapter 1, you can list multiple profiles in your <head>. So if you are using both hCard and XFN, for example, you can declare both profiles together:

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

Also, as I mentioned in Chapter 1, a combined profile for all formal microformat specifications is in development. Once completed, it will provide a more efficient profile declaration.

For example, since hCard and XFN are formal specifications, you will be able to just declare the single combined profile, rather than each micro-format’s profile.

Be sure to check http://microformats.org/profile/ for information about this forthcoming combined profile.

Syntax

hCard is a compound microformat that comprises many properties and subproperties.

The root property of hCard is vcard (remember the 1:1 representation with vCard properties?). All contact information must be contained by an element (any element) that is assigned class="vcard". And as the root property, this value cannot be combined with any other hCard property values.

fn is the only required property for hCard (other than the root vcard). This is assigned to content that is a person’s (or organization’s or place’s) formatted name.

What is a formatted name? Basically it is a string (more than one word) equivalent to a person’s name as it would appear on a nameplate or label. This could be Ms. Emily P. Lewis or Lewis, Emily or, in the case of an organization, Badass Tattoo Company. Here is a simple example of a person hCard using only the required fn property:

<p class="vcard"><span class="fn">Emily Lewis</span></p>

Information about people

There are a number of properties and subproperties specific to people.

Names

The n property represents a person’s structured name, and you use it to indicate that content contained by an element assigned class="n" represents parts of a person’s name, such as first, middle, and last.

When you specify the n property, you must also specify its relevant subproperties:

• given-name is applied to content representing a person’s first name.

• additional-name is commonly used for a person’s middle name, but can be used more than once for people with many parts to their names.

• family-name indicates a person’s last name.

• honorific-prefix indicates honorific name prefixes, such as Mr. or Dr. This subproperty can be used more than once.

• honorific-suffix is applied to content for honorific name suffixes such as PhD or Esq. This, too, can be used more than once.

If your content doesn’t have name components for all of these n subproperties, don’t worry. They are optional. Use only what you need for your content.

The n property is often used alongside fn, since the content is, typically, the same:

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

However, if the content is strictly two words representing first and last name, the n value is implied; it isn’t necessary to specify it or its subproperties:

<p class="vcard"><span class="fn">Emily Lewis</span></p>

On the other hand, if the content is more than first and last name, you do need to specify n, along with its relevant subproperties.

Also, a reminder from Chapter 1: you cannot combine subproperty values with the parent property value. As such, class="n given-name" would be invalid.

The other name-related property for people hCards is nickname, which (can you guess?) indicates a person’s nickname. This might be the affectionate name your family calls you (though my sister still insists “Rugrat” was not that affectionate), or it may even be something like your Twitter handle.

Organization/employment

If a person’s contact information includes references to employment or association with an organization, there are several properties you can use.

The org property indicates the name of the person’s employer or organization with which they are affiliated. You simply contain that organization name with an element assigned class="org".

org has a few subproperties:

• organization-name indicates the full name of the organization. This subproperty, however, can be implied (that is, left out of your implementation) when the content contained by the parent org is just the organization’s name:

<p class="org">Pitney Bowes Business Insight</p>

• organization-unit indicates the department (division, unit) a person works in or is affiliated with. In my case, that would be Marketing. So if you wanted to include department information in your org content, you would contain it in an element assigned class="organization-unit".

In this case, you would also have to specify the organization-name subproperty so that machines could properly parse the name as separate from the department:

<p class="org"><span class="organization-name">Pitney
Bowes Business Insight</span> <span class="organization
-unit">Marketing</span></p>

If your hCard content is even more specific, you can implement these additional organization-related properties:

• title specifies a person’s official job title, such as Executive Vice President.

• role specifies a person’s role in relation to an organization or company. For example, goalie is a role on a sports team.

• The agent property is applied to content indicating another person who can act on behalf of the individual, such as an assistant. This property is most often assigned to a link (<a>) with an href value of the other person’s (the agent’s) own hCard.

• logo is a property that indicates the logo associated with the person’s organization. It is applied to either an <img> or <object> element whose href value is a URL to a graphic of the organization’s logo.

Other personal identification

Finally, here are the last personally identifying properties for hCard:

• The photo property is applied to either an <img> or <object> element whose href value is a URL to a photo of the person.

• bday indicates a person’s date of birth. And remember, when dealing with dates, the machine-readable data is specified as an ISO 8601 value.

Information specific to organizations (and places)

So, I’ve covered the properties for people. And unbeknownst to you, I’ve also covered the properties for organizations, which are the same properties and subproperties for an individual’s contact information related to their employment or organizational affiliation:

• org property

• organization-unit subproperty of org

• organization-name subproperty of org

• logo property

When marking up an hCard for an organization, the syntax is slightly different than that for people. Remember the required fn property? This is also applied to an organization’s formatted name. But since the formatted name is most often the same as org, you combine the two values:

<p class="fn org">The Washington Post</p>

You would use this same class="fn org" syntax if you were also indicating content for the org subproperties:

You may now be wondering about places (since I so cleverly included that in the previous subheading). And I’m here to tell you that hCard syntax for named places is, essentially, the same as that for organization hCards.

Named places are more like organizations than they are like people. They have a name, an address, perhaps even a website and logo. But they don’t have family names, birthdays, or job titles. So in the markup for a named place, hCard uses the same name syntax I describe above for organizations:

<p class="fn org">The Washington Monument</p>

All the rest

The remaining hCard properties and subproperties can be applied, as needed and relevant, to information about people, organizations, and places.

Addresses

The adr property specifies address information, and it can be used multiple times in an hCard, such as to provide both home and work addresses.

Content contained by an adr element is broken up into components that are assigned various subproperties via the class attribute:

• post-office-box indicates PO Box information.

• extended-address is applied to content for apartment or suite numbers/letters.

• street-address indicates the street address.

• locality is for city information.

• region is applied to state and province content.

• country-name indicates country information.

• postal-code indicates the ZIP Code.

The last adr subproperty is type. This is not a component of the address, but rather the type of address, such as work or home. The only accepted values for type are as follows:

• home

• work

• postal indicates it is a postal mailing address.

• parcel indicates it is a parcel/package delivery address.

• intl indicates it is an international address.

• dom indicates it is a domestic address.

• pref indicates it is the preferred address if you have more than one adr for your hCard.

To indicate these values, you specify an element with class="type" and the inner text equivalent to one of the values:

<p class="adr"><span class="type">Home</span> ...</p>

In case you were wondering, these type values are case insensitive. So don’t be concerned about the casing for the inner text.

Also you can use multiple type values where they make sense. So if you have a home address, which is also your preferred address and a domestic delivery address, you can use all three values, separated with a comma:

<p class="adr"><span class="type">Home, Dom, Pref</span>
...</p>

But what if you don’t care to display these actual values to your users? You want to give the machines extra semantic yumminess, but you would prefer users to see something more human-friendly. Your solution is the value-title subset of the value class pattern.

If you recall from Chapter 1, you can use an empty <span> assigned class="value-title" to indicate the machine data is specified in the element’s title attribute. Just contain this empty <span> within your type subproperty, making sure it immediately follows its parent element:

<p class="adr"><span class="type"><span class="value-title"
title="home dom pref"> </span>My preferred residential
address:</span> ...</p>

Notice that the multiple type values are separated by spaces in the title attribute, and that the more human-friendly text immediately follows the empty <span>.

If you do not specify a type value, machines default the type values to intl, postal, parcel and work. Translated into English: the address is an international work address for both postal and parcel deliveries.

label is the other property you can use for address information, but this is an address you do not care to break up into its various components (adr subproperties). It is primarily intended for content that specifies an actual delivery address label that you might, for example, print for shipping.

Like adr, label has an optional subproperty of type and the values are the same (home, work, postal, parcel, intl, dom, and pref). Also, as with adr, if you don’t define a type for label, the default type values are intl, postal, parcel and work.

And finally, you can use adr and label together if you care to specify your address information with all of its components and indicate it is content appropriate for a delivery label:

Email and websites

The email property of hCard indicates email information and can be used multiple times in an hCard if you care to specify more than one email address. You should apply email (via the class attribute) to hyperlinks that specify an email address:

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

Machines extract the email address data from the href value, after removing the "mailto:" prefix.

You may also want to indicate what kind of email addresses your hCard contains with the type subproperty. Similar to type for adr, you create a class="type" element and use it to contain the accepted values (case insensitive):

• internet says that it is an Internet email address.

• x400 says that it is an X.400 address.

• pref indicates it is the preferred address.

• Any registered IANA (Internet Assigned Numbers Authority) address value

In order to indicate type, though, your email property cannot be applied to the <a> element, because type is a subproperty and needs to be contained by the email element.

For these situations, you use the type property along with the value property (the value class pattern) assigned to the email link:

Once again, if you don’t care to display these type values as content to your users, you can use the value-title subset of the value class pattern to provide machine data via the title attribute of an empty <span class="value-title">.

Another option is to use the abbr design pattern to display appropriate information to your users and give machines the data they want via the <abbr> title attribute:

In this example, note how the <abbr> is assigned the type subproperty, and the actual values (yes, you can specify more than one) are in the title attribute.

Of course, keep in mind that the abbr design pattern results in a browser tooltip with the title values and the potential for screen readers to expand the title. If you have any concerns that this may cause accessibility or usability problems for your audience, consider the value-title subset of the value class pattern instead.

In addition to email addresses, you can indicate what type of email software a person (or place or organization) uses via the mailer property. There aren’t any specified values for this property. You simply contain the name of the email software (for example, Microsoft Outlook) with an element assigned class="mailer".

Finally, to specify website information for a person, place, or organization, you use the url property of hCard. The best semantic markup for this content is, obviously, a hyperlink (<a>):

<a class="url" href="http://www.ablognotlimited.com">my
blog</a>

Telephone numbers

You use the tel property to indicate telephone numbers, and it can be used multiple times in an hCard:

<span class="tel">505-123-4567</span>

And like adr and email, you can use the type subproperty to specify the type of phone number based on these values:

• home

• work

• voice

• fax

• cell

• pager

• modem

• msg indicates the number has an answering machine.

• video indicates the number is for a videoconferencing system.

• bbs indicates the number is for a bulletin-board system.

• isdn indicates it is an ISDN (integrated services digital network) number.

• pcs indicates it is a PCS (Personal Communications System) number.

• car indicates it is a number for a car phone.

• pref indicates the number is preferred over any other numbers you provide in your hCard.

When no type is specified, machines default to voice.

<p class="tel"><span class="type">Home</span> <span
class="value">505-123-4567</span></p>

Notice in this example that in addition to <span class="type">, I have a <span class="value"> containing the actual number information. This is just another example of the value class pattern to differentiate the type from the actual number data.

But you don’t even have to use the value property. If your tel property only contains the type information and the number, machines recognize that whatever isn’t contained by class="type" is the number data:

<p class="tel"><span class="type">Home</span> 505-123-4567
</p>

Geographical information

With the tz property, you can specify the time zone where a person is currently located (or an organization or a place exists). Common implementations of tz utilize the abbr design pattern, where the <abbr> element is assigned class="tz" and the value for time zone is specified in the title attribute:

<p>I live in the <abbr class="tz" title="-7:00">Mountain
Time</span> time zone.</p>

Note that the time zone value is specified in UTC-offset, which is the Coordinated Universal Time offset by the number of hours (in this example, seven) the specified time zone differs.

Also keep in mind the accessibility and usability issues related to the abbr design pattern. If you are concerned that the –7:00 value will be read aloud to screen-reader users or display in a browser tooltip, the value-title subset of the value class pattern can also be used for time zones:

<p>I live in the <span class="tz"><span class="value-title"
title="-7:00"> </span>Mountain Time</span> timezone.</p>

You can provide even more geographic information in your hCard with the geo property, which indicates the global position of a person, organization, or place.

geo has two subproperties:

• latitude for locations north and south of the equator

• longitude for locations east and west of the prime meridian

The values for these two subproperties must be specified as decimals and to six decimal spaces for accurate GPS (Global Positioning System) locations:

Realistically, there aren’t going to be a lot of instances where you would want to display this latitude/longitude information to your users. But I can see a very valuable use of this information for machines, such as mapping and GPS applications.

You can choose to use the abbr design pattern, taking into account usability and accessibility needs:

<abbr class="geo" title="35.089612;-106.618318">GPS location
</abbr>

Note that with this design pattern, your latitude and longitude are listed together as the <abbr> title value, respectively, separated by a semicolon.

And yet again, if you are concerned about the usability and accessibility of the coordinate data, you can use the value-title subset of the value class pattern for geo coordinates.

The kitchen sink

The remaining hCard properties cover the rest of the fields in vCard (again, remember that whole 1:1 representation I mentioned?):

• The category property is used to indicate keywords that describe the contact information. For example, a category value for my contact information is “web design.”

These categories can be thought of as tags and, as such, you could use the rel-tag microformat along with the category property:

<a class="category" rel="tag" href="http://www.technorati/
tag/webdesign">web design</a>

And category can be repeated, as needed, to describe your hCard.

• class indicates the access classification of the hCard information, whether it is public, private, or confidential. In practice, this property is little used, as there are better methods of providing access restrictions on the web.

• key specifies the public key or authentication certificate for the contact.

• You use note when you have supplemental information (a note, duh, or a comment) for your hCard; it can be used multiple times, if needed. Machines combine multiple instances of note into a single note value.

• rev is applied as a class value for date-time information indicating the last revision of the hCard information. Don’t confuse this with the rev attribute for hyperlinks, as used with VoteLinks. In hCard, rev appears as class="rev" applied to an element containing date-time information.

• sort-string indicates how the name information should be sorted by machines. For example, if you wanted an application to extract the information and sort it based on last name, you would apply the sort-string property to the family-name:

• sound indicates the hCard contains audio content to supplement the content. Most frequently, this is a sound file that provides the proper pronunciation of the name.

• uid specifies a unique global identifier for the contact, typically an IANA format. In practice, publishers have used uid to specify which url of an hCard is the primary or uniquely identifying URL.

The syntax for these properties is the same as the others: the property name is assigned to an element via the class attribute.

What to use?

Because of hCard’s 1:1 relationship with vCard, there are a lot of properties (if you didn’t already notice). Where vCard has a field, hCard has a property.

And all of these properties and subproperties may seem completely overwhelming to you. I have to admit, you aren’t alone. In fact, I’ve only personally used about a third (or less) of these hCard properties for my own hCards. My content just hasn’t (yet) required agent or geo or sort-string.

Just do me a favor: don’t actually get overwhelmed. Instead, focus on your content. What hCard properties/subproperties are relevant? Once you know those, craft your hCard to suit your content’s needs.

And, if it makes you feel any better, the majority of the tools supporting hCard don’t use every single one of these properties. For the most part, hCard applications support the properties for the most common of contact information: name, address, telephone, email, website, organization.

That doesn’t mean you shouldn’t use any of these hCard properties. If you have the content that can benefit from the extra semantic value, apply the relevant properties. You can always create your own tools, and you never know when someone else will come up with some amazing application that uses the entirety of hCard.

Practical Markup for People

So far, I’ve shown you a bunch of disparate code snippets just to give you a flavor for the properties, subproperties, and syntax. Now it is time to look at some practical hCard examples using good ol’ POSH.

hCard in natural language

One of the simplest ways to apply hCard is in natural language. We’ve already taken a look at this during our exploration into XFN. I mentioned that I often reference my friends’ and colleagues’ names in my blog posts, and I always give them some link-love.

<p>At SXSWi, I attended an excellent session on the future
of web education, along with my friend <a href="http://www.
webteacher.ws/">Virginia DeBolt</a>.</p>

In Chapter 4, we looked at applying the rel attribute to those links, but hCard is a good fit too, since I have the person’s name (the only content required for hCard) and a website.

Required root property: vcard

First step, add the vcard root property to my parent element:

<p class="vcard">At SXSWi, I attended an excellent session
on the future of web education, along with my friend <a
href="http://www.webteacher.ws/">Virginia DeBolt</a>.</p>

Required property: fn

Next, I need to assign the required fn property to the element containing my friend’s name:

<p class="vcard">At SXSWi, I attended an excellent session
on the future of web education, along with my friend <a
href="http://www.webteacher.ws/" class="fn">Virginia
DeBolt</a>.</p>

Remember, because the inner text of my fn element is exactly two words representing first and last name, the n property is implied and I do not have to use any subproperties.

Optional property: url

As it turns out in this example, the element containing the name also happens to be a link to the contact’s website. So I can add the url property right alongside fn:

<p class="vcard">At SXSWi, I attended an excellent session
on the future of web education, along with my friend <a
href="http://www.webteacher.ws/" class="fn url">Virginia
DeBolt</a>.</p>

Combining XFN and hCard

I hope it has already occurred to you by this point: the hCard content can be further extended with XFN.

The person in this example content is a friend, I have met her, and she is a muse, so I add those values to the rel attribute of the hyperlink:

<p class="vcard">At SXSWi, I attended an excellent session
on the future of web education, along with my friend <a
href="http://www.webteacher.ws/" class="fn url" rel="friend
met muse">Virginia DeBolt</a>.</p>

The end result

And with just a few class values and the rel attribute, you have hCard and XFN in one:

<p class="vcard">At SXSWi, I attended an excellent session
on the future of web education, along with my friend <a
href="http://www.webteacher.ws/" class="fn url" rel="friend
met muse">Virginia DeBolt</a>.</p>

Personal site/blog contact information

On almost every single personal site and blog on the web, you will find contact information for the person who maintains it. Most times, this information is “chunked” in a fashion you would see in an address book entry, with name, email, website, address, and maybe even a photo:

<p><a href="mailto:[email protected]">Emily Lewis
</a></p>
<img src="EmilyLewis.jpg" alt="Emily Lewis" />
<p><a href="http://www.ablognotlimited.com">A Blog Not
Limited</a></p>
<p>Albuquerque, <abbr title="New Mexico">NM</abbr></p>

Required root property: vcard

You will note that the content for this example is broken up into block elements (<p>), and I want to keep that structure in this case. But I need to contain everything with the root vcard property. Therefore, I add a containing element to my markup:

Required property: fn

Next, I apply the fn property to the element containing the content of my first and last name. Once again, I don’t have to include the n property:

Optional property: email

The name information is contained by an email link, so I can also add the email property:

Optional property: photo

The <img /> in this example is to a photo of the contact (me in this example, because I’m incredibly vain):

Optional property: url

This example includes website information, so I also add the url property:

Optional property: adr

Finally, for the address information, I add the adr property, along with the relevant subproperties for city and state:

Notice I had to add a nonsemantic <span> for my locality property because that content didn’t have the element “hook” I assign the microformat class name.

Combining XFN and hCard

Yes, once again, we are going to add XFN to our hCard (this is quickly going to become familiar to you). Because we are dealing with hCards for people in these examples, it makes perfect sense to include XFN (which describes relationships among people).

In this particular example, I’m describing myself. So what XFN value would we use? You got it: me.

Just as a reminder, the rel attribute is assigned to the link containing the URL to my site, and the value me indicates the site is part of my online identity.

Combining rel-home and hCard

But we aren’t restricted to just XFN in combination with hCard. Because the content in this example includes a link to my site and this is content that appears on my site, I could also add rel-home:

If you recall from Chapter 3, the rel-home microformat indicates that the destination of the specified link is the site’s home page.

The end result

Once again, a dash of new markup, a sprinkling of classes, a few rel attributes, and we have three microformats applied to a single set of content:

The logic behind the markup

In this example, I chose to use <p> block elements to contain my data, which required the addition of the nonsemantic <div> to serve as my root element. This is a personal choice, as the markup isn’t relevant to the hCard. And I wanted to use block elements to help with the display of the content.

There are other options. I could put all this information in a list, with a <ul> serving as the root element, and <li>s containing the content. I could even use a <dl>. Hell, I could use a bunch of <span>s.

Another element that might be appropriate is <address>, which is used to contain the contact information for the site or page. In this example, that is exactly the type of content we are dealing with. So this might be the most semantic option:

So why didn’t I choose this markup? First, <address> can’t contain block-level elements (like <p>), and I did want that particular markup structure in this example.

But that’s a fairly lame justification because display/presentation is easily controlled with CSS, and I could apply display:block to any of my classes. What it really comes down to is personal preference.

As for you, go with the structure that makes semantic sense for your content. If you use the <address> element, though, be certain you are using it correctly. It is only for contact information for a document (a site or a page), not necessarily the author of the document (though the two can be the same). Just remember, <address> shouldn’t be used for just any hCard.

Blog comments using <ol>

Another type of content for which you might want to apply hCard is blog comments. When someone submits a comment, bloggers typically capture name and website, sometimes a photo.

Let’s take a look at the basic markup for a couple of blog comments:

Required root property: vcard

Because my list contains comments from multiple people, I do not want to apply the root vcard to the root <ol>. Instead, vcard is applied to each <li>, which contains the contact information for each person:

Required property: fn

Next, apply the fn property to the element containing each person’s name:

Optional property: url

The element containing the name also happens to be a link to the person’s website, so I also add the url property:

Optional property: photo

The last bit of contact information we have for each person is a photo:

The end result

After applying all the properties, the final markup is:

The logic behind the markup

As with any content, there are dozens of approaches to markup. And let me say it again (because repetition is the spice of life): hCard doesn’t care what your markup is. So why an ordered list in this example?

From my perspective, an ordered list is a great semantic element for blog post comments. People submit comments at different times, so I like the sequential properties of <ol> to indicate which comment was first, second, and so on.

Additionally, <li>s can contain almost every markup element. So I can nest headings, images, paragraphs, even lists to accommodate not only the commenter’s contact information but also their actual comment.

Simple as that.

Employee directory using <ol>

So far, the examples for people-based hCards have been simple, with just name and basic contact info. How about we add some more hCard properties to the mix?

One example of content that would include additional contact information is that which you might see in a corporate employee directory:

Required root property: vcard

First I apply the root vcard to the element (<li>) containing each contact’s information:

Required property: fn

Next I apply the fn property to indicate each contact’s formatted name:

Required property: n

Because the names in this example are more than two words representing first and last names, I must use the n property along with the appropriate subproperties for given-name, additional-name, and family-name:

Note that in order to apply the n subproperties, I had to add nonsemantic <span>s to contain the relevant content.

Optional property: email

I apply the email property to the link containing each contact’s email address:

Optional property: photo

The contacts in this example each have a photo, so the photo property is applied to each <img />:

Optional property: org

This example includes organizational information for the contacts’ employer, so I need to add the org property. And because the organization content includes not only the organization name, but also the department, I need to add the subproperties organization-name and organization-unit:

Once again, note that I added <span>s to contain the org subproperties.

Optional properties: title and role

The content for each of these contacts also includes their job title and role:

Optional property: tel

Each contact also has multiple telephone numbers listed, so I include the tel property, as well as the type subproperty to differentiate the two different numbers:

You may notice that for the type subproperty, I added <em>s instead of <span>s to contain the content. That’s because, in this content, I think <em> is a good semantic element as it offers a bit of emphasis to the content that is describing the type of telephone number.

Optional property: bday

I also assign the bday property to each contact’s date of birth, using the value class pattern to indicate my ISO 8601 machine data:

For the birthday content, I used the value-title subset of the value class pattern to indicate my date information. This is to eliminate potential issues with screen readers and browser tooltips.

However, because the bday value is only the date (not date and time), you can also use <abbr> with the value class pattern:

<p>Birthday: <abbr class="bday" title="1857-01-01">January
1</abbr></p>

This implemention still results in a browser tooltip and potential screen reader expansion, but the value class pattern allows for this method of separately indicating ISO 8601 machine information for date and time.

It is only the use of <abbr> with a combined date-time value (AKA, the datetime design pattern) that is deprecated.

The end result

And after all of the relevant properties and subproperties have been assigned, we get this final markup:

The logic behind the markup

Typically, directories are listed in alphabetical order, so once again, I chose an unordered list due to its inherent sequential nature. I like that I can nest block-level elements in the <li>s for all of the contact information, particularly <h5>s for each person’s name, which can help with search engine optimization.

But I could’ve done it differently using a definition list within each <li> for the contact information:

In this approach, the <dt> contains the person’s name information, and all the subsequent <dd>s contain information that describes the person in fuller detail. This is an acceptable use of a definition list. I could even move the root vcard from the containing <li> to the <dl>. Don’t you love having so many options?

Practical Markup for Organizations (and Places)

The following examples focus on hCards for organizations and places. A lot of what you’ll see will be familiar, because the syntax is almost the same as it is for people hCards.

Corporate-site contact information using <dl>

Any corporate site provides contact information for the organization. Or at least sites for companies with content authors who aren’t idiots do.

The approach is the same as in the example I provided for contact information on a personal site, but this time I’m going to use a definition list as the markup container:

Required root property: vcard

Because this example is for just one organization, I apply the root vcard to the containing <dl>:

Required properties: fn and org

Next, I assign the required fn and org properties:

Optional property: logo

This example includes a logo for the organization, so the logo property is applied to the <img>:

Optional property: adr

This example includes two addresses: one for the street address and one for mailing (postal). As such, I want to assign the adr property to each, and be sure to differentiate the two addresses with the type subproperty.

And because I’m using adr, I also need to assign the various subproperties to the address components:

Once again, for the address components that need an element hook to assign the subproperties, I’ve added <span>s.

Also note that for the type subproperty, I am using the value-title subset of the value class pattern to provide machines the type data, but not to display that information to my users.

Optional property: label

Because this example includes a PO Box that is indicated as the mailing delivery address (via parcel), it may also make sense to add the label property to that address:

Optional properties: email and url

This example includes links for the organization’s website and email, so I add the url and email properties:

Optional property: tel

I’m providing both phone and fax numbers in this example, so I want to be sure to specify not only the tel property for each, but also the type subproperty:

Note that Phone is not a valid type value, so I’m using the value-title subset of the value class pattern to indicate a value of work for that number (via title). Fax, however, is a valid type value, so that content does not need the addition of the value class pattern.

Optional property: geo

My original content did not include geographical coordinates, but let’s say you wanted to include those (perhaps to leverage Yahoo! Placemaker functionality).

You can include that information for machines and not display it to your users, if you like, using the value-title subset of the value class pattern:

Note that I applied the geo information (completely fictional, by the way) to the street address, rather than the PO Box, as that is the content the geo coordinates describe.

The end result

And our final markup looks like:

The logic behind the markup

The reason behind using a definition list for this content is that all of the contact information describes the company. So the company name and URL are contained by the <dt>, and all of the additional contact information appear within the <dd>s, which, from a semantic markup perspective, relate to that <dt>.

You may also have noticed that the address information is contained by unordered lists nested within <dd>s. Why? Well, I really think address information can be thought of, semantically, as list information.

Corporate directory for multiple branches using <dl>

Let’s say you work for an organization that has branches in, perhaps, many different locations, and you are tasked with putting together an online directory that provides contact information for each:

Required root property: vcard

Because my content contains multiple contacts (a different one for each branch), I need to assign the vcard root property to each:

Required properties: fn and org

Not only do I need to include the required fn and org properties for each branch’s name information, I also need to specify the org subproperties, so that I can differentiate between the branches (via organization-unit):

Depending on your presentational requirements, you may not want to display the main organization name (Helping Hands) for every single branch; you may want your users to see only the branch name.

But you need the organization name for machines to properly parse your hCards. What to do? Just use some clever CSS (display:none) for the organization-name.

I know, I know. Hiding content with CSS is generally frowned upon. But mostly that’s when it’s used for black hat SEO purposes. Still, I don’t like to do it. Sometimes it may be necessary, though. Decide for yourself.

Optional property: url

The organization’s website is included in this example, so we also include the url property on the link:

Optional property: adr

Whenever you add the adr property, be sure to include the relevant subproperties for all the address components:

Optional properties: email and tel

Last, I add the email and tel properties. And because I’m specifying more than one phone number for each branch, I also include the type subproperty:

Once again, make note of the value-title subset of the value class pattern for the Phone tel type. I’m indicating a valid value with the inclusion of an empty <span class="value-title"> that has work in the title.

The end result

All of the properties and subproperties results in this final markup:

The logic behind the markup

I’m hoping it is already obvious to you why I chose the markup for this example, because it is very similar to the other examples I’ve described:

• The <ol> is appropriate for the sequential (alphabetical) nature of the listing, and each <li> can contain the block-level content I wish to use for my contact information.

• The nested <ul>s for address information suit my semantic perspective that such content is really just a list.

• The same logic applies to the nested <ul>s containing email and telephone information: list content.

Alternately, I could’ve used a <dl> nested in each <li> for my contact information; however, I wanted the extra “SEO power” of the <h5> for each branch.

It’s really up to you. Think about your content and consider the markup structure that is most semantic and appropriate for your needs.

Natural language for a named place

Last, but certainly not least, let’s look at an example of an hCard for a named place. As I said, it is essentially the same as an hCard for an organization:

<p>One of the best road trips I have ever taken was to
Graceland in Memphis, Tennessee.</p>

Required root property: vcard

First, we start with the required root property:

<p class="vcard">One of the best road trips I have ever
taken was to Graceland in Memphis, Tennessee.</p>

Required properties: fn and org

Because this example is for a named place, not a person, you use the org subproperty to indicate the place’s name, along with fn:

<p class="vcard">One of the best road trips I have ever
taken was to <span class="fn org">Graceland</span> in
Memphis, Tennessee.</p>

Because my example did not have an element I could use as a hook for these two properties, I added a <span> to contain Graceland.

Optional property: adr

Once again, I add <span>s to provide the containing elements needed to assign adr and its relevant subproperties.

<p class="vcard">One of the best road trips I have ever
taken was to <span class="fn org">Graceland</span> in <span
class="adr"><span class="locality">Memphis</span>, <span
class="region">Tennessee</span></span>.</p>

Optional property: geo

Finally, it seems this particular hCard would benefit from some geographical coordinates. But, as with my other examples, I don’t care to display that content to my users, so I will use the value-title subset of the value class pattern:

<p class="vcard">One of the best road trips I have ever
taken was to <span class="fn org"><span class="geo">
<span class="value-title" title="35.046862,-90.023239">
</span>Graceland</span></span> in <span class="adr">
<span class="locality">Memphis</span>, <span class="region">
Tennessee</span></span>.</p>

Notice that in this instance, I’ve applied geo to the name content rather than the address content. That is because the coordinates describe the named place (Graceland), rather than the city and state.

The end result

That handful of properties and subproperties we added gives us:

<p class="vcard">One of the best road trips I have ever
taken was to <span class="fn org"><span class="geo">
<span class="value-title" title="35.046862,-90.023239">
</span>Graceland</span></span> in <span class="adr"><span
class="locality">Memphis</span>, <span class="region">
Tennessee</span></span>.</p>

Authoring Tools

Not a fan of hand-coding? I won’t make fun of you (to your face, at least).

Seriously, though, hand-coding isn’t for everyone and it is, arguably, inefficient at times. So here are a number of resources to help you author and validate your hCards:

• hCard creator: http://microformats.org/code/hcard/creator

• Optimus microformats transformer (for validation): http://microformatique.com/optimus/

• hCard microformat validator: http://hcard.geekhood.net/

• hCard cheat sheet: http://microformats.org/wiki/hcard-cheatsheet

Just the Beginning

As you may have noticed, hCard is one of the more detailed microformats. Lots of properties and subproperties to choose from. Lots of design pattern options for indicating enumerated values of the adr and tel type subproperties. Lots of choices when it comes to markup.

It seems like a lot because it is a lot. But in many ways, understanding the details of hCard gives you a great foundation for the microformats you’ll be learning about in future chapters.

You are well prepared now to dive into the next microformat, hCalendar, which can be combined with hCard and also can utilize the geo property we’ve already covered.