As of today, Facebook has marked up all events with the hCalendar microformat including marking up their venues with hCard as well. According to a simple Google search, that’s millions of public events now with microformats (if anyone knows a more precise number for the total number of Facebook events including private ones, or how many events are created per day, please let us know!).
Here’s an upcoming example: the Great British Booze-up at SXSW 2011 (which I highly recommend if you’re into high fidelity markup, as a bunch of us will be there sharing drinks and post-future-panel microformats conversations).
Visit it in a browser that supports microformats (there are now plugins for Chrome, Firefox, Internet Explorer, and Safari). E.g. try Firefox 4 with the Operator Add-On, and you’ll see “Events (1)” in the toolbar. Just one click reveals “Great British Booze-up” which you can then choose to export to your iCal, 30 Boxes, Google, or Yahoo calendars.
And if you’re a user, that’s it. The ability to copy events to where you want them. If you publish hCalendar, Google will index and show rich snippets for your events. That’s what microformats empower you to do.
For the web authors/designers/developers out there, let’s take a closer look at Facebook’s markup. If you view source on the page and search for “vevent”, you see the following code:
<body class="vevent ...
Which indicates that this page is an event. Searching further in the source you’ll find that Facebook generates the rest of the from a script. While this isn’t ideal (in general it’s better to have the markup in markup), apparently there are sometimes performance reasons for script generated content. No matter, we can use Firefox’s “View Selection Source” context menu to view the generated markup.
I want to call out two specific aspects of Facebook’s implementation. Select the entire date time row: “Time Monday, March 14 · 6:00pm – 9:00pm” and right/control-click on it and choose “View Selection Source”. Here’s most of the markup you’ll see (white-space added for readability).
<div>Monday, March 14 ·
<span class="dtstart">
<span class="value-title" title="2011-03-14T18:00:00"> </span>6:00pm</span> -
<span class="dtend">
<span class="value-title" title="2011-03-14T21:00:00"> </span>9:00pm</span>
</div>
Minor update 2011-02-18: The “-07:00” timezone offsets were removed as they were not reliably accurate. Better to omit the timezone offset, use floating datetimes and let the consumer infer timezone from location as needed.
Encoding dates and times that work for humans and machines has been one of the biggest challenges in microformats, and what you’re seeing here is the result of years of community iteration (techniques, feedback, research) called the ‘value-title’ technique of the value class pattern. In short, by placing the machine readable ISO datetime into the title attribute of a harmless empty span element adjacent to the human readable date and time, we are able to achieve a pragmatic balance between user experience, content fidelity, and minimizing the effects of what is essentially duplicating the data (a DRY violation, something we avoid due to potential inconsistencies unless absolutely necessary for a greater principle, such as usability – humans first as it were).
This is the largest deployment of the ‘value-title’ technique known to date, and works great with the value class pattern support in Operator.
Let’s take a look at the venue. View Selection Source on the entire block from “Location Shakespeare’s Pub” to “78701” and you’ll see (again with whitespace added)
<div class="location vcard">
<span class="fn org">Shakespeare's Pub </span>
<div class="adr">
<div class="street-address">314 East 6th Street</div>
<div class="locality">Austin, TX 78701</div>
</div>
</div>
This is an excellent example of using a nested hCard for an hCalendar event venue, except for one thing:
<div class="locality">Austin, TX 78701</div>
Which should be marked up more like:
<span class="locality">Austin</span>,
<span class="region">TX</span>
<span class="postal-code">78701</span>
I’m guessing what’s going on here is too coarse of an interface between a backend and frontend system, that is, for convenience the developers may be retrieving the entirety of the city, state, and zip from their backend as a single string, and thus the best the front end can do is to mark up the entire thing as the city (locality).
While not ideal, this isn’t horrible either. Using Operator again, choose “Export Contact” for Shakespeare’s Pub, and note that your address book displays it just fine (even if the fields aren’t exactly in the right spots). Copy and pasting that address to a map site also works. The markup isn’t ideal, but it’s usable and useful, and I for one am happy that Facebook chose to go ahead and make that pragmatic decision and ship now, while knowing they could iterate and improve data fidelity in a subsequent update.
Facebook’s deployment of hCalendar is just the latest in their series of slow but steadily increasing support for open standards and microformats in particular. Over two years ago Facebook added hCard support to their user profiles. Last year they announced support for OAuth 2.0, as well as adding XFN rel-me support to user profiles, thus interconnecting with the world wide distributed social web. They proudly documented their use of HTML5. And now, millions of hCalendar events with hCard venues. Looking forward to seeing what they support next.
Well done Facebook, and keep up the good work.
Frances 
Tantek