Because I forget stuff. Part of

Note: It appears you must have reached this page by a deep level URL. In general this site is currently down and unmaintained. See here

About This Post

Originally posted April 25 2007 at 21:04 under Web. 1 Comment. Trackbacks Disabled.


Thoughtful (tiny, little thoughts)
Still James :-)

Microformats have been the new buzz around those building semantic websites for a while now. I’ve thought of playing with them before, but I’ve never really got them. To be more accurate, I’ve got the concept, and the idea behind them, but I’ve never felt comfortable with the implementation details. Anyway, when I wrote a recent review on this blog I decided to have a bit of a play. These are my thoughts having gone through that process; I’m still not convinced…

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=""></a> Web: <a href=""></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="" class="email"></a> Web: <a href="" class="url"></a></span>

Note the amount of extra markup required in the second case. The examples given on 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>

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.

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>

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.

Comments (1):


Just a quick addition to this, so I’ll comment here rather than make a complete new post. there’s an article from The Web Standards Project which attacks the use of abbr elements in the datetime-design-pattern. That use was the thing which struck as the most wrong when putting together my hreview. I did briefly wonder what the hell a screen reader would make of it and from that article it seems I was right to do so. I’d go further though, and claim that abbr is simply semantically incorrect. In my case the ISO 8601 date format and the human readable version were conveying exactly the same amount of information so it seems that at best the two are equivalent and at worst the abbreviation is, as I initially felt, the wrong way around.

It is interesting to note from the article that the use of abbr came about as a workaround—it was not the first choice. Marking up datetime information is actually something I’ve thought about before. It seemed then, as it still does now, the the main problem is the lack of semantically correct elements available (I’m far from convinced by the use of object that was the original plan).

Are microformats interesting and useful? Yes, they are, and they certainly have potential to link together various aspects of the online world. The whole forced in as an after thought shoe-horning feel is still there though; perhaps that is an unavoidable consequence of what they are trying to achieve.

Made by Ian Scott on Apr 27, 2007 at 12:08

Post a comment

Name and email address are required. Email address is never shown. If you enter a URL your name will be linked to it (this and other links will have the rel attribute set to contain nofollow). Markup allowed: <a href="" title="" rel=""> <em> <strong> <abbr title=""> <acronym title=""> <p> <br />. Anything else is stripped; please be valid. Single linebreaks automatically convert to <br />, double to <p>'s. Additionally anything that looks like a bare URL should get automagically linked. Many acronyms and abbreviations are also automagically handled.

Please note this blog's comment policy

Trackbacks (0):

Trackback URL:


This Crazy Fool

Dr Ian Scott
Croydon (and Gateshead), United Kingdom
Bullding Services Engineer (EngDesign), PhD in Physics (University of York), football fanatic (Newcastle United), open source enthusiast (mainly Mozilla)

More about me [Disclaimer]

You may subscribe to IMS_Blog using the RSS Feed, the Atom Feed or by email.

Creative Commons License

From April 25 Other Years

© Ian Scott. Powered by Movable Type 3.2. This blog uses valid XHTML 1.0 Strict and valid CSS. All times are local UK time. For further details see the IMS_Blog about page.. All my feeds in one.