Microformats are getting more and more popular among Web2.0 services and you only need to have visited Web2.0 Expo in Berlin (and probably others) to actually see that. Now I was always a bit sceptical about them and their actual use for some reasons. One of these is actually the fact why you put information for machines actually inside the human visible content. It always seemed a bit complicated to me. The other reason was how you actually use this information. I’d think it’s easier for e.g. an event database to provide an API for searching than to just the hevent microformat and rely on scraping their site. Actually most of those microformats seem to belong (in my limited view ;-) ) in the realm of indexing services. Services, I don’t want to run.
Now with the release of the Social Graph API from Google it of course makes a bit more sense, at least for Google. They already have that information in their databases and a good running indexing service. So to utilize this information seems to be a natural move (at least from a technical POV).
But the #microformats IRC channel finally got a bit more active and so I had the chance to listen to Tantek explaining the reasoning behind them a bit (hope I got this right):
- Hidden information is bad information because it might be out of sync or it’s not clear then what actually is revealed there.
- based on the premise that everything should be human readable, too.
- There is a plethora of formats and thus it’s arbitrary data which is not useful at all.
One must say that this is true, not too many standards (maybe except FOAF and even this is not widespread) have reached some general use and as we see it today Microformats seem to gain momentum (esp. now with all the talk about Data Portability).
Microformats as HTML classes
One thing though is still bothering me and this is the use of HTML classes (I mistakenly said CSS classes but of course Tantek was right when he corrected me and said it’s not just for CSS). So these classes are used for CSS or scripting and with the AJAX framework in KSS in Plone we actually use them in yet another context (probably in general that’s scripting). And he of course is also right when he says that the use of HTML classes for semantic purposes is older than the use for styling reasons.
Fact is though that the use for styling is much more widespread than this for semantic markup. The problem I actually have right now is getting Plone to have more Microformats support. The specific problem lies in the vcard class which is used in Plone’s default template for events. I can only guess why such a class is used there and it’s probably because this class existed already for a nice tabular markup and was reused in the event class because in this case it’s used in a tabular display of the events details.
Now vcard is actually part of the hCard microformat and seems to be wrong here. Instead it should be an vcalender class (and additional attributes/classes for the content of the table) because this is what the hCalendar standard defines. But I cannot simply change it because people who have customized Plone might have redefined this class to show the events page differently and if I remove that class they might have a broken page. Thus backwards compatibility would be broken.
The fixed names of Microformats
Now this wouldn’t be so bad in one case maybe but I see a general difference here between the use in CSS classes and scripting which is: While you can choose your own classes for CSS and scripting you cannot choose class names for Microformats because they are fixed.
Now this maybe is my main problem with Microformats. What actually happens if more and more Microformats get defined? Do I have to rename my classes then eventually? This might not be a problem if you are creating one standalone application or service where you control the class namespace yourself and you can simply change a classname and replace them everywhere. But when creating a product of framework for various services and widespread deployment it’s not that easy anymore.
Well, probably this is a minor problem and I also wonder if I can work around that by maybe defining a vcalendar class inside the vcard class but who knows if not some parsers might get confused by this.
I am also not sure what can be done to avoid this. One solution might be to use maybe prefixes for Microformats so that people know that every class which starts with „mf-“ should not be used because it might be a microformat markup. But maybe it’s too late already for such a change.
Another spontaneous idea was to use some mapping which would be a separate maybe CSS-style like syntax which defines which class in the document defines which part of which microformat. But this probably has many disadvantages like again having a separate file, making parsing way more difficult and so on. So this wouldn’t be the way either.
Anyway, probably it’s just a minor problem but I nevertheless blog about it just because I am having that problem now ;-)
And while I think Microformats are in general great because they find more and more adoption and I also actually want to use them deep in my heart I probably still like separate documents better ;-)
Technorati Tags: microformats, dataportability, plone, development