Getting semantic and DRY with microformats and Radiant CMS

Brian Dillard, Tuesday, April 1, 2008 @ 1:09 pm

I can now cross Microformats off my list of "technologies whose value I recognize even though I've never had the chance to use them in real life." Last week I created three hcards for the new Pathfinder website, one each for our Chicago headquarters, our New York office, and our head of sales. Now, if you've got a browser plug-in that can parse microformats, you can import our contact information directly into Outlook, Apple's Address Book or your PIM of choice.

A little background

Microformats, for those who don't immerse themselves in grassroots front-end technologies, are at the core of what's become known as the "semantic web." The basic idea is that by adopting a set of standardized markup patterns, we can create websites that are more easily parsable by both humans and machines. More from the "About microformats" page:

Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards. Instead of throwing away what works today, microformats intend to solve simpler problems first by adapting to current behaviors and usage patterns (e.g. XHTML, blogging).

The most popular and best-known microformat is the hcard, an HTML implementation of the standard vCard format used to store and exchange address and personal information in a wide variety of software applications. If vCards are basically electronic business cards that can be imported to or exported from your contacts manager, then hcards provide the same functionality in the browser.

Current browsers usually support microformats via a plug-in (though that's evolving). Firefox's plug-in is called Operator. There's also at least one plug-in for Safari. For IE, you've pretty much got to rely on bookmarklets. I suspect the same is true for Opera, but please correct me in the comments.

So where's the value?

Enough theory. What do microformats actually add to the new Pathfinder website?

For users, our new hcards add the ability do export contact info directly from the browser. This functionality is shown in the screenshot.

For developers, our new hcard snippets help achieve the DRY principle. After creating a reusable Radiant CMS snippet for each of my hcards, I can use the same code to output contact information on any page. And thanks to the power of CSS, I can control how that contact info looks from one page to the next. If I need to output a full range of contact details on one page but just a name and a phone number on another page, the same markup can be used in both instances.

The boring technical details

As with many of our reusable Radiant snippets, the trick to getting DRY with my new hcards is to invoke them inside containers with specific classes applied. Based on those container classes, CSS then turns off the display of certain parts of the hcard so it looks the way my users (and designers) expect. The result is contant that's equally human- and machine-readable.

Here's the hcard markup for Paul Dittmann, our sales director:

<div class="vcard">	<div class="fn n">		<span class="given-name">Paul</span> 		<span class="family-name">Dittmann</span> 	</div>	<a class="org url" href="http://www.pathf.com">Pathfinder Development</a>	<div class="adr">		<span class="type">Work</span>		<div class="street-address">215 W. Superior St.</div>		<div class="extended-address">Suite 400</div>		<span class="locality">Chicago</span>,  		<abbr class="region" title="Illinois">IL</abbr>  		<span class="postal-code">60610</span>		<div class="country-name">USA</div>	</div>	<div class="tel">		<span class="type">Work</span>		<span class="prefix">+1-</span>312-372-1058 ext 6006	</div>	<a class="email" href="mailto:pdittmann@pathf.com">pdittmann@pathf.com</a></div>

Here's the CSS that controls the basics of our hcards. A few bits of the content - such as address and telephone types and the phone prefix - are there only to make the hcards machine-readable. For a U.S. audience perusing a corporate website, they're useless. We therefore disable the display of those elements.

#content div.vcard .org {	font-weight: bold;}#content div.vcard .country-name,#content div.vcard .adr .type,#content div.vcard .tel .type {	display: none;}#content div.vcard div {	margin: 0 !important;	padding: 0 !important;}#content div.vcard abbr {	text-decoration: none;;}#content div.vcard a.email {	display: block;}#content div.vcard .tel .prefix {	display: none;}

Now we set up some additional rules to disable the display of still more content in certain situations. Rather than configure a whole bunch of specific use cases, I find it's easiest to just set up multiple classes, each of which will disable the display of one specific hcard component.

#content .noAddress,#content .noCompany,#content .noPhone,#content .noEmail{	margin: 0 !important;	padding: 0 !important;}#content .noAddress div.vcard .adr {	display: none;}#content .noCompany div.vcard .org {	display: none;}#content .noPhone div.vcard .tel {	display: none;}#content .noEmail div.vcard a.email {	display: none;}

Now, finally, to output just Paul's name, email address and phone number, I invoke my snippet like this:

<div class="noCompany noAddress">	<r:snippet name="2008vcardPaulDittmann"/></div>

I've got similar snippets set up for the hcards for our New York and Chicago offices. When I display these in the browser, I want to offer more details. But there's no point in repeating the company name. Therefore, I invoke my snippets like this:

<ul class="noCompany">	<li>		<strong>Chicago Office</strong>		<r:snippet name="2008vcardChicago"/>		<a class="mapLink" href="/about-us/where-to-find-us/chicago-office/">map &amp; directions</a>	</li>	<li>		<strong>New York Office</strong>		<r:snippet name="2008vcardNewYork"/>		<a class="mapLink" href="/about-us/where-to-find-us/new-york-office/">map &amp; directions</a>	</li></ul>

Voila: A perfectly workable first stab at reusable contact snippets. There's plenty more we could do with microformats - and probably will. We could encode latitude and longitude information into our existing hcards so they can be understood by mapping applications. We could start using microformats in our blog bylines and event calendars. The possibilities are many, varied - and expanding all the time.

agile ajax

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   The one thing i did with my django-site:

   If the user wants to subscribe to his events as ical/vcard, render the xhtml, then pipe the output through http://suda.co.uk/ ’s hcard/hcal-xslts. This is DRY at his best.

   Comment by Peritus, Wednesday, April 2, 2008 @ 5:32 am

Leave a comment