In response to my introduction, Andy Hume asked me on the Microformats-discuss list:
What kind of microformat support are you looking to get in to these publishing tools? Obviously wordpress has built in support for XFN. What else are you trying to get happening?
So now it’s time for me to put on my visionary cap and mention a couple ideas I’ve been stewing on about why microformats make good sense for web publishers and web tool builders. I won’t get too pedantic or preach to the choir. Rather, I’m just gunna outline some of the obvious things to me that make creating the lowercase “semantic web” worthwhile, assuming, of course, that certain enabling technologies and innovations occur.
First, let me point out that the cost of implementing microformats is less than minimal and in fact, in some cases, can give you a net gain given the reduction on time spent figuring out what CSS classes to use. As a former-web-developer-junkie, it was my job to come up with unoriginal ways of identity bits of content on webpages so that I or someone else could come back later and figure out what the heck I was doing.
This lead to me to do things like code lists of people with a container that specified that, indeed, I was working with a list of people and not dates, dogs or envelopes. Why would this be useful? Well, what if you wanted to use a different icon to denote a person, date, dog or envelope? You’d need to know what class of object you were working with. (Just bear with me here.) This becomes a pain when you have to do this over and over again and or work on someone else’s code. However, with a sufficient store of standard microformats at our disposal, such situations could theoretically be avoided. Rather than having to reinvent a classing system everytime, I could simply turn to the related microformat standard and call it a day.
So that’s great and all, but why do you bother touching code anymore anyway with such able CMS and blog tools available? Why not just bake it into those publishing tools and be done with it?
The short answer is that that’s happening, and we need to see more of this work get done. The problem seems to be related to chickens, eggs, carts and horses, in no particular order. And until they all get sorted out, there’s a great deal of developer apathy best captured in lines like, “Why should I care?”
Well, better than just spouting out about the practical benefits for web developers, there are functional benefits which I expect to see available in the coming months. As a prelimary example, check this out:
I created a Greasemonkey user script that will find those hCalendar events and provide a link to import them into any calendar program that supports the iCalendar format (most notably Apple’s iCal and Mozilla’s Sunbird). What does this mean? Well any time you see an event on the web that has hCalendar information, you can click a link and it’ll be added to your calendar so you don’t have to copy the information by hand.
So just imagine once this kind of support becomes native in the browser… that’s when really interesting things start to become possible. And soon, I’ll outline just how I see this happening.