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:

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:

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.

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.

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.

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.