Stuff & Nonsense Home

Where you’ll find designer, author and speaker Andy Clarke. The bastard.

Blogging And All That Malarkey

A tribute to Microformats (a reader question answered)

Enrique Ramírez wrote to me yesterday with a few questions about Microformats and markup. I’ve been asked these questions before, a few times. So rather than send Enrique my answers on a postcard, I’m replying in public, with Enrique’s permission of course.

Enrique wrote,

This is to notify you that your e-mail has won 250,000.00 euros in the 2008 SPNL Sweepstakes e-Lottery.

No wait, that was somebody else. And I'm still waiting for my damn money.

I've been reading your latest blog post and there are some things I don't really agree with. Why use Microformats? They really look like an excessive amount of tags and classes to me. They also seem to have very few benefits.

While I agree that id's and classes should reflect the function of the element, what's more important? Writing simple, semantic code or writing tag-heavy code with lots of classes and id's that perfectly define each element function? Here's an example that comes to mind:

<div class="vcard">
<div><a class="fn org url" href="#">Stuff and Nonsense Ltd.</a></div>
<div class="adr">
<div class="street-address">The Cow Shed Studio</div>
<div class="locality">Eversleigh, Gwaenysgor</div>
<div class="region">Flintshire, North Wales</div>
<div class="postal-code">LL18 6EJ</div>
<div class="country-name">UK</div>
</div>
<div class="tel">01745 851848</div>
</div>
</div>
</div>

Here comes why I'm against Microformats. It looks to me like an abuse of tags (improper tags, too) and classes. The same semantic value (although without as much specificity) can be approached with something like:

<div class="vcard">
<a href="#">Stuff and Nonsense Ltd.</a>
<address>
<strong>The Cow Shed Studio</strong>
Eversleigh, Gwaenysgor<br />
Flintshire, North Wales<br />
LL18 6EJ<br />
UK<br />
</address>
<em>01745 851848</em>
</div>

It's not as specific (meaning not tagging every element for what it is), but the semantic value is there. Probably even more since we're using the actual tags for what they should be, instead of a <div> which, to my understanding, is a group of elements that form a division of the layout.

So why use classes to add semantic value when there's a tag that already has semantic value to it? Do search engines already support classes? Do speech readers?

These are fair questions and it's also fair to say that I was asked almost all of them after a talk packed with Microformats in Amsterdam earlier this year. It's also fair to say that not quite two years ago I asked almost exactly the same questions to Jeremy during a long flight to San Francisco.

A tribute to Microformats

Firstly, it is true that on first impressions, the sheer number of Microformat class attribute values looks excessive. But in the case of mature and widely adopted Microformats such as hCard and hCalendar, each one of these attribute values comes not from the vivid imaginations of the inventors of Microformats, but have been reused from existing, related standards such as vCard and vCalendar. In fact, these attribute values are one-to-one correlations between the two formats and it is this that, for example, makes writing conversion scripts such as Brian Suda's X2V possible.

If you're thinking that implementing Microformats means a return to sneezing class attributes all over your markup, you possibly also take exception to often div and span laden markup that is often used in Microformats examples and that generated by generators such as the hCard Creator.

But it's important to remember that Microformats need not always be constructed this way. Instead, you can construct it using markup elements that are appropriate to the context of the content you're publishing. Take this example of the hCalendar Creator formatted Visual Web Design Master Class.

<div class="vevent">
<a class="url" href="#">
<abbr class="dtstart" title="2008-12-01T09:00Z00">Dec 1, 2008  09.00am</abbr> – 
<abbr class="dtend" title="2008-12-01T17:30Z">5:30pm</abbr> :  
<span class="summary">Visual Web Design Master Class</span> at 
<span class="location">Central Saint Martins College of Art and Design</span></a>

<div class="description">Join Andy Clarke and special guest 
Brendan Dawes for a special full day learning how you can create 
masterful designs for the web.</div>
</div>

Is the choice of div and span appropriate for this content in the context that I published it?

No.

In fact I published that same information in two different ways on this site, both using markup elements that were appropriate to the context in which I published it. First I published that content as tabular data, so a table element, enhanced with specific hCalendar attribute values was the perfect choice.

<table class="vcalendar">
<tr class="vevent">
<td class="dtstart"><abbr title="2008-12-01" class="dtstart">01/12/08</abbr></td>
<td class="summary"><a href="#" class="url">Visual Web Design Master Class</a></td>
<td class="location">Central Saint Martins College of Art and Design</td>
</tr>

[...]

</table>

In another context, I published that information in a list of events (ordered of course).

<ol class="vcalendar">
<li class="vevent">
<h3 class="summary"><a href="#" class="url">Visual Web Design Master Class</a></h3>
<p class="location">Central Saint Martins College of Art and Design</p>
<p class="dtstart"><abbr title="2008-12-01" class="dtstart">01/12/08</abbr></p>
</li>

[...]

</ol>

If you are new to Microformats, it is so important to remember that both the Microformat class attribute values and the most appropriate choice of elements add meaning to your content.

Content with added meaning through Microformats need not always follow the markup constructs that we so often see on the web. Infact, that markup can be extremely flexible.

You know that HTML is the root element of your document, right? Well the root element of any Microformat is its name, vcard, vevent or hentry. Place those names as an attribute on any logical, containing element and that element becomes the root element of the Microformat. This might be a ul, a table, a div or in some cases even the body element of a document. When you free yourself from thinking that Microformats must follow often div and span laden markup and again use the most appropriate HTML elements, your markup will be super meaningful.

You can find more about how I use Microformats and markup in this way in a series of articles that I wrote this year for Peachpit.

  1. Microformats: The Fine Art of Markup
  2. Microformats: The Fine Art of Markup: hCard
  3. Microformats: The Art of Markup: hCalendar
  4. Microformats: The Fine Art of Markup: hReview
  5. Microformats: The Fine Art of Markup: hAtom

Do search engines already support Microformats?

Technorati provides a Microformats search for contacts, events and reviews published with hCard, vCalendar and hReview and Google's Social Graph API searches XFN. The Yahoo team is passionate about Microformats and Yahoo Creative Commons Search uses rel-license.

Does using Microformats currently improve SEO? According to this recent article, How microformats affect search engine optimization (SEO), the answer is not yet, but it is inevitable.

Currently microformats affect SEO the same way content on your website affects it. From a web crawlers perspective there is currently no distinguishing factor between a microformat and standard content on your website. [...] Let’s face it, one day search engines will have no choice but to take microformats into consideration and they will certainly benefit because of doing so. [...] It’s a snowball effect that is happening right this moment.

As to whether screen reader users benefit or not from our use of Microformats, the answer is possibly and no. There have been some concerns from accessibility specialists over the use of the abbr title markup pattern for dates and times and until there is an agreement over if there is a better alternative is resolved, the debate will no doubt continue.

But whether or not people have disabilities, using Microformats to add deeper, more precise meaning to content can only be of huge benefit. Add that to the opportunities that can come from making services that process Microformat content and consider the low cost of implementing them and I hope you'll conclude like I have, that it's almost unjustifiable to mark-up a document without them.

Leave your comment

patrick h. lauke

November 17 2008 @ 10:29am #

yes, the usual bone of contention regarding the datetime pattern’s use of abbr and the full iso format. IF i use a screenreader and IF i have it set to expand ABBR, i get a lengthy string of gobbledigook. now, i know master jeremy will soon shout “bollocks” and explain that the full iso date is in fact MORE accessible because it removes the ambiguity of what is a month and what is a day in the all too similar UK and US variants in common use, but then i ask: if it’s so much better, why not use full iso in your page even for sighted users? why hide it in an ABBR title? maybe because it looks crap,  but we can live with it sounding crap?

Andy Clarke

November 17 2008 @ 10:38am #

@Patrick H. Lauke: Oh no, here we go on the ‘Highway To Hell’. I knew there would be trouble, the minute that I played AC/DC’s ‘If You Want Blood’ while writing this.

patrick h. lauke

November 17 2008 @ 10:44am #

not highway to hell, just the same argument that we’ve put to the microformats community for almost two years now, with no satisfactory resolution. but yes, keep that head in the sand :)

Andy Clarke

November 17 2008 @ 10:48am #

@Patrick H. Lauke: I’m well aware of that argument. My pragmatic question on that is “does the edge case of IF i use a screenreader and IF i have it set to expand ABBR overpower the huge gains you can make with say hCalendar?” It’s not an ideal world, so I’m going to say no.

Emily Lewis

November 17 2008 @ 10:51am #

Enjoying the recent microformats posts. Particularly your practical explanations of _how_ to implement them.

I’ve been blogging a fair amount about microformats lately, in large part to do the same: offer practical information about the hows and whys.

As much as I find the microformats wiki useful, I also find it difficult (at times) to extract good, semantic examples from it that I’m comfortable implementing.

Regarding the accessibility issues. Yes, they are a concern and need to be addressed. But I don’t feel they warrant _not_ using microformats to enrich the web.

Perhaps the more people write about microformats, the more people will use them, the more development to take advantage of them AND a greater (faster) push to address accessibility concerns with the datetime pattern ...

patrick h. lauke

November 17 2008 @ 10:57am #

fairy snuff. if you’re seeing huge gains, more power to you.

from my own experience, it’s the actual use of microformats parsers (both client and server-side) that is an edge case:

a) joe sixpack / the plumber doesn’t use Operator in Firefox or similar

b) search engine style indexers have heuristics to translate human-readable dates/times into unambiguous dates which work well most of the time (just as google maps search doesn’t require lat/long but can do fine with human readable addresses),

c) if you use a database to power events listings and contact listings etc you can generate them separately in vCard, iCal, etc.

but yeh, i’m happy to agree to disagree.

Cole

November 17 2008 @ 11:01am #

div and span laden

Aren’t they hiding in a cave somewhere?

Remember kids, if you’re going to use the address element for creating hCards remember that this element should be used to supply contact information for the document being viewed and not more generally for anyone Tom, Dick or Harry’s contact details. Also, being an inline element it’s a lot more selective than divs in terms of what markup it can contain.

Stay safe!

Cole

November 17 2008 @ 11:11am #

PS I feel inclined to agree with Patrick on the hCalendar front although do feel that this should not hinder us using microformats to add meaning and machine readability to our websites where accessibility issues do not occur. Now, has anyone got a cushion as sitting on this fence is giving me a sore bum?

Ross Bruniges

November 17 2008 @ 04:05pm #

Probably blowing my own trumpet here but if you want to see some microformaty action on a live site using (hopefully) better mark-up than the generic stuff that the microformats “create a” tool do have a butchers at the london guide project I worked on….

www.capitalradio.co.uk/london-guide/ - do a search and view an event/venue page

André Luís

November 18 2008 @ 09:32am #

Andy, a very important point that I usually use is the fact that today you can already create “applications” to enhance search results at Yahoo! using SearchMonkey.

It’s indexing an incredible ammount of pages with microformats, so the advantages are here now. With or without extensions… Brian Suda’s X2V has proven invaluable in that area.

Numbers from october 21st:
hcard - 1,390,000,000 pages
hatom - 366,000,000 pages
xfn - 277,000,000 pages
hcalendar - 48,900,000 pages
hreview - 53,900,000 pages

Impressive, no?

Enrique Ramírez

November 19 2008 @ 05:34am #

Thanks a lot for your fast response. I just got time to read it. Glad to know you’re not bound to certain tags on microformats and what’s really important are the classes you asign.

Although I still feel the bennefits are really not that great when standing infront of the disadvantages (I believe accessibility is first) and I still prefer not to use microformats, at least now I know that whenever I have to work with them, I can do so with more flexibility.

Thanks for taking the time for replying. ;) I’m certainly experimenting with these in the near future. :)

Commenting is not available in this channel entry.
Hardboiled Web Design

Hardboiled Web Design by Andy Clarke

How the latest technologies and techniques will make your websites more creative, flexible and adaptable. Get hardboiled in all formats from Five Simple Steps. Digital formats also available at Amazon.com, Amazon.co.uk and the iBooks store.

We’ve deconstructed this site to focus on content while we restyle. Expect wonkiness during the transition.