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>
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.
So what this also means is that services indexing the web and searching for events can now capture these as they are communicated in a standard fashion, right?
February 17th, 2011 at 12:54 pm
Also, might this not kill the non-standardization of venues/places across multiple services like Foursquare, Gowalla, Facebook etc?
February 17th, 2011 at 1:09 pm
Marshall, the interaction of search engines and Facebook has always been interesting so we’ll see what happens in the coming days.
Given that Facebook and Google are now both supporting the same open standard for sharing event information, there’s a lot of potential here.
And regarding standardization of venues across services, that’s still quite a challenge. However I will say one thing, the sites that support hCard venues will get better re-use and better results, so in that regard, it’s currently a competition among all such sites to see which supports hCard on their venue pages with highest fidelity.
February 17th, 2011 at 1:17 pm
This is really great news. It might not be too dramatic right now, but the more browsers support microformats the better the user experience will be.
February 17th, 2011 at 1:42 pm
Identity and time are meta-memes. hCard/hCal make it so any compliant app can then post events and identity elements into Facebook if authorized?
February 18th, 2011 at 9:42 am
Supporting microformats is a fine move, but what good is it if the interaction with data trapped inside of Facebook remains just as restricted as before ?
February 24th, 2011 at 5:00 am
Jean-Marc: But that’s exactly the point – that’s what’s changed!
It’s now easier to interact with the data inside Facebook – re-read the post.
You can now use browsers and browser plugins (like Firefox 4 with Operator) to add your event information to the calendar of your choice – purely based on open standards – hCalendar and hCard.
That’s new with Facebook’s microformats support, and less restricted than before.
February 24th, 2011 at 4:20 pm
I’m looking everywhere for a complete list of all usable categories for the
eventType (category) – Example: “Festival”, “Concert”, “Lecture”.
Where can I find them ?
There are some limitation or I can put anything I want ?
April 2nd, 2011 at 6:25 am