IMS_Blog

When I say I haven’t played with microformats before it’s not strictly true. If you look down the bottom of this post you’ll see a load of tags which is an implementation of rel-tag. The main page blogroll also contains XFN codes on some of the links, and I’ve used vote-links before. I think it’s noticeable that all those cases are single attribute additions, and more or less to elements already present in the markup (rel-tag may be arguable here—would the markup be present at all if I weren’t using tags—but in principle at least I could use the links without the rel attribute to declare them tags, so it feels like the same sort of category). Where I seem to become uncomfortable is with microformats which require more additions, nesting, and which, in fact, might lead to the addition of markup for no other purpose than to meet the microformats requirements.

[It should probably be noted I haven’t really fully thought all this through. I’m just noting down ideas and thoughts here]

An example seems to be in order here: Take the following, which we can then “markup” using hcard:

Dr Ian Scott Email: <a href="mailto:ian@norcimo.com">ian@norcimo.com</a> Web: <a href="http://www.norcimo.com">norcimo.com</a>

(We’ll forget for a moment that there may be better ways of semantically marking this up in the first place…)

Now, marked up using hcard:

<span class="vcard">Dr <span class="fn">Ian Scott</span> <a href="mailto:ian@norcimo.com" class="email">ian@norcimo.com</a> Web: <a href="http://www.norcimo.com" class="url">norcimo.com</a></span>

Note the amount of extra markup required in the second case. The examples given on microformats.org tend to be replete with soups of span elements, going so far as to give the following:

<span class="tel"><span class="type">Home</span> (<span class="type">pref</span>erred):
<span class="value">+1.415.555.1212</span></span>

http://microformats.org/wiki/hcard

I can’t help but feel that the first line of that contains something which is simply ugly code.

Of course microformats advocates will argue the obvious point that carrying more information requires more markup, and at least span and div are semantically empty. That very thing tells you something though: What is being cried out for is more markup. There is nothing in the document to say anything about what something with a class of vcard should mean. Clients simply have to parse the entire document in case such a thing exists and then assume it’s a microformat—I could easily have randomly used that class name all on my own (it wouldn’t be a very good class name obviously, but hey. And whilst on the subject, even though it’s based off vcard, why is the “base class” of the hcard specification still vcard??).

The CSS specification actually says something interesting:

Note. CSS gives so much power to the “class” attribute, that authors could conceivably design their own “document language” based on elements with almost no associated presentation (such as DIV and SPAN in HTML) and assigning style information through the “class” attribute. Authors should avoid this practice since the structural elements of a document language often have recognized and accepted meanings and author-defined classes may not.

http://www.w3.org/TR/CSS21/selector.html

Whilst the specification is talking in a somewhat different context it’s a useful warning to bear in mind. Microformats such as hcard etc do design a document language to some extent, and while their class names may have accepted meanings if you happen to know the right microformat to look at, there is nothing in the document to tell you so.

This is my overall impression of most microformats: They are shoe-horning in an almost ad-hoc solution where the markup is simply lacking. Is it not better to correct the lack of markup than to continually force things to act beyond the bounds in which they were designed to operate? The formats I gave at the top that I’m more comfortable with I’m more comfortable with because they are using rel and rev in a way much closer to that originally intended.

I think this can be demonstrated by one further example. Imagine, if you would for a moment, that the definition list did not exist. It is a very small step to conceive a microformat advocated as something like:

<ol class="definitions">
<li class="definition"><span class="item">Mercury</span> <span class="define">A heavy, silver-white elemental metal, atomic number 80</span> <span class="define">The nearest planet to the Sun</span> <span class="define">In Roman mythology the messenger of the gods</span></li>
<li class="definition"><span class="item">Venus</span> <span class="define">The second closest planet to the Sun</span> <span class="define">In Roman mythology the goddess of love and beauty</span></li>
...
</ol>

That’s just off the top of my head; you could undoubtedly refine it down a bit but you get the general idea. The point is nobody could seriously advocate such a thing because the definition list, dl, does exist. The problem microformats are trying to solve is the lack of a “person” element, or a “review” element.

I think that what I’m saying is that if you’re going to extend there need to be ways to extend (easily) with actual markup, rather than forcing in things which only make sense if you guess right. In fact hreview seemed to force me into code I don’t find particularly correct. As the date and time of my posts are presented to readers I thought I should use that for the dtreviewed field. However, that requires an ISO 8601 date time. Unless I’m missing something then the only way to get things to work using the already present date and time was to place that within an abbr element, so I ended up with something like: <abbr title="20070424T1904">April 24 2007 at 19:04</abbr>. To me, that is entirely the wrong way around. Surely 20070424T1904 is an abbreviation of the contained April 24 2007 at 19:04, not vice versa? In fact it feels so wrong that it might get removed at some later date. In fact this is another example of trying to make things act beyond their designed scope. What is really needed here is some sort of date element.

There is one final thing I wanted to mention regarding microformats: The ease of use. While it’s true it’s a simple matter to markup a bit of standalone code, it didn’t seem such an easy task to integrate them into an already established automated publishing process. I had to go hunting in the templates, and give serious though to exactly where I needed to be applying class names, not just for the review I was writing but for future possibilities too. Perhaps some of that is a reflection on my own monolith of code, but I think it shows that microformats are not necessarily a “drop in” idea.