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.
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
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
span appropriate for this content in the context that I published it?
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
div or in some cases even the
body element of a document. When you free yourself from thinking that Microformats must follow often
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.
- Microformats: The Fine Art of Markup
- Microformats: The Fine Art of Markup: hCard
- Microformats: The Art of Markup: hCalendar
- Microformats: The Fine Art of Markup: hReview
- 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
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
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.