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.
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
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.
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.
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.
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).
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).
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).
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.
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.
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?
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.
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>
There are a number of properties and subproperties specific to people.
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.
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.
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>
The remaining hCard properties and subproperties can be applied, as needed and relevant, to information about people, organizations, and places.
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 value
s 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:
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>
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
• 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>
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 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.
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.
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.
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.
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>
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.
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>
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>
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>
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>
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:
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:
email
The name information is contained by an email link, so I can also add the email
property:
photo
The <img />
in this example is to a photo
of the contact (me in this example, because I’m incredibly vain):
url
This example includes website information, so I also add the url
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.
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.
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.
Once again, a dash of new markup, a sprinkling of class
es, a few rel
attributes, and we have three microformats applied to a single set of content:
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 class
es. 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.
<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:
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:
fn
Next, apply the fn
property to the element containing each person’s name:
url
The element containing the name also happens to be a link to the person’s website, so I also add the url
property:
photo
The last bit of contact information we have for each person is a photo
:
After applying all the properties, the final markup is:
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.
<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:
vcard
First I apply the root vcard
to the element (<li>
) containing each contact’s information:
fn
Next I apply the fn
property to indicate each contact’s formatted name:
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.
email
I apply the email
property to the link containing each contact’s email address:
photo
The contacts in this example each have a photo, so the photo
property is applied to each <img />
:
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.
title
and role
The content for each of these contacts also includes their job title
and role
:
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.
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.
And after all of the relevant properties and subproperties have been assigned, we get this final 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?
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.
<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:
vcard
Because this example is for just one organization, I apply the root vcard
to the containing <dl>
:
fn
and org
Next, I assign the required fn
and org
properties:
logo
This example includes a logo for the organization, so the logo
property is applied to the <img>
:
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.
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:
email
and url
This example includes links for the organization’s website and email, so I add the url
and email
properties:
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.
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.
And our final markup looks like:
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.
<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:
vcard
Because my content contains multiple contacts (a different one for each branch), I need to assign the vcard
root property to each:
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.
url
The organization’s website is included in this example, so we also include the url
property on the link:
adr
Whenever you add the adr
property, be sure to include the relevant subproperties for all the address components:
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
.
All of the properties and subproperties results in this final 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.
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>
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>
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.
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>
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.
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>
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
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.