IMS_Blog

I’m still sort of thinking out load here, this isn’t anything like a definitive, finished version of my opinions. I’m still thinking and reading.

I think i may have been a bit harsh on microformats. Particularly I gave the definition list example, as a way microformats would compensate for the lack of a definition list (i.e. for the lack of available elements). This is though partly exactly what microformats are trying to do—be a relatively simple and still somewhat semantic (or at least, not un-semantic (is that a word?), way to compensate for the things we are missing. There is something else that microformats do which I failed to mention, perhaps because I hadn’t fully appreciated it—they define context (in machine readable terms, rather the context which may be evident to a human reader). Even if we had a datetime element (such as in HTML 5’s time) microformats allow you to say that is the datetime of an event, or when a review is being written, or whatever the context of that datetime is. Of course one may argue that what is actually needed is an hreview element, or an event element, but as said microformats are also doing their best to work around the lack of available elements too.

To be honest, some of the immediatly obvious alternatives (RDFa, Embedded RDF for instance) follow the exact same shoe-horning approach, a soup of specialise classes (and even custom attributes) applied to the pre-existing elements. A distinct lack of simply being able to write <vcard title="Ian Scott">... or something similar. And it does all beg the question: If we’re working with XHTML, which is XML, why not just import the appropriate namespaces? Maybe because that seems oh so complicated (surely it’s no more complex than learning some frankly obscure schema to assign the right classes in the right place), and more importantly, because it can’t really be applied to plain old HTML, and you can’t expect any old client to have a clue what’s going on either.

So, perhaps, microformats are a useful way forward, at least in the medium to long term. They have to avoid semantic traps—perhaps given their nature to build upon content already in place they should steer clear of any semantically meaningful element. This might occasionally mean something like <span class="microformat"><abbr title="Something">... when an abbreviation really is semantically relevant to the content, but so be it, there’s enough spans get inserted just for the sake of microformats already that one or two more wouldn’t make a difference.

One thing that has crossed my mind, not that I’m very comfortable with it, is that perhaps we’re putting all this information in the wrong place. If display:none; is used so much to hide bits (and how does the document look with stylesheets turned off?), and we’re trying to surround everything with code just for the machines, what about comments? As I said, just an uncomfortable thought.

One final thought for now: Is there actually any point—I’ve yet to actually use a feature of the Operator extension for instance, other than to go ohhh, look, a microformat (then, I’ve never really the whole tagging thing either). It’s an emerging field, so it’s difficult to tell. While being one click away from adding an event to your calendar, say, sounds attractive exactly how many times do you do that in an average week?