Microformats, Key Flaws

Post from July 16, 2009 (↻ November 14, 2020), filed under Web Development.

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

I like the idea behind microformats, but I’m still not convinced of the way that idea is brought to life. I see three major flaws that appear to make microformats stand in their own way. Being somewhat distant to the microformats community I claim to be unbiased: Here are my concerns.

Microformats don’t aim high enough to make software do the work, not authors. Microformats allow to associate more meaning with markup. This meaning can be extracted and accessed by software. Microformats require, however, special code for about every bit of meaning they try to uncover. That means, microformats don’t utilize HTML as well as they could, and instead offload work and an unnecessarily high burden on authors.
Microformats block class names. I already wrote about that in 2007—Microformats shouldn’t occupy class names but instead use “pseudo-namespaces.” Class names like location, description, and url are likely to be used by authors in other contexts. That authors can style the respective elements differently and override rules for microformats doesn’t mean they should be forced to do so. The problem reminds me of the times when HTML 5 included predefined class names. There’s a good reason why they got removed.
Microformats are “too easy.” Subjectively, everything, from simple attribute-value pairs to single class names, can nowadays become a “microformat.” What data back up the decisions to make something a microformat; who truly has the foresight and authority to turn such suggestion into a microformat?

For a counter-example, let’s look at how hCalendar could define event markup in a more elegant fashion (based on one of the hCalendar samples):

<div class="vevent">
<h3>XYZ Project Review</h3>
<p>Project XYZ Review Meeting</p>
<p>To be held on <abbr class="vevent-dtstart" title="1998-03-12T08:30:00-05:00">12 March 1998 from 8:30am EST</abbr>
until <abbr class="vevent-dtend" title="1998-03-12T09:30:00-05:00">9:30am EST</abbr></p>
<p>Location: <span class="vevent-location">1CP Conference Room 4350</span></p>
<small>Booked by: <span class="vevent-uid">guid-1.host1.com</span> on
<abbr class="vevent-dtstamp" title="19980309T231000Z">9 Mar 1998 6:00pm</abbr></small>
</div>

We’d use vevent as the pseudo-namespace, and remove the summary and description classes as one could work with headings to carry the summary, and p elements to provide the description. A rough sketch of how we could address the concerns listed above (though the abbr problem would still remain).

About Me

I’m Jens Oliver Meiert, and I’m a web developer and author. I love trying things (including philosophy, art, and adventure). Here on meiert.com I share some of my views and experiences.

If you have a question or suggestion about what I write, please leave a comment (if available) or a message.

Comments (Closed)

On July 16, 2009, 12:26 CEST, Ciaran McNulty said:
1 - I’m not quite sure what you mean here, but I think you’re saying that the semantics should be encapsulated in HTML elements? That’s certainly true and something that should be pushed for in future HTML versions. I’m sure existing microformats will be expanded to use new HTML5 elements when they’re added, say.

2 - Microformats do ‘reserve’ certain class values, but in a lot of cases are non-obvious (an example is vevent, it’s hard to see that coming up accidentally). They also recommend the use of the HTML @profile attribute to disambiguate (this could be seen as a very coarse page-level namespace).

3 - Well the ‘council’ is the Microformats community and your second example is a pattern rather than a microformat, but I don’t really understand the criticism - the point of them after all is to be microformats.
On July 16, 2009, 14:03 CEST, Neal G said:
I complete agree with you on #2. I don’t think microformats should reside in the class element.
On July 16, 2009, 15:50 CEST, Chris Cressman said:
1. I’ve found hCalendar tedious to author at times, but I generally find microformats to be very easy and intuitive to author by hand. Most authors, however, don’t author by hand, and there are tools to automate the markup for those who want to use them. The best part about microformats is they are in constant development by the microformats community. Anyone with criticisms (or even better, suggestions for improvement) can participate in the development process.

2. Once you become familiar with microformats, you know which class and rel values are used and they are easy to avoid. As implied, there is a learning curve to overcome, but microformats are much easier to learn than other “micro data” solutions. HTML authors already know how to use class and rel, you just need to learn the values. And again, if you disagree with the particular attribute values (or which attributes are being used) you can actively take part in the ongoing development of microformats to help shape them in the future.

3. I recommend reading the microformats process if you haven’t seen it. There is a wealth of information on the microformats wiki explaining how microformats are developed. Microformats are also influenced by parties who are not directly part of the microformats community. See the blog post announcing the value-class-pattern for an example (the value-class-pattern also addresses your concern over the abbr-design-pattern).
On July 16, 2009, 18:32 CEST, Tim Wright said:
Have you looked into RDFa at all? It’s more intense coding, but takes Microformats a step further towards being machine readable content. And RDF takes it even further than that into the Semantic Web.
On July 16, 2009, 21:44 CEST, Stefan Asemota said:
@j9t The abbr issue is definitely an accessibility “flaw” and the reason many of my colleagues lost interest. The extra code for each element makes them less attractive initially though I personally feel that the added-value using them is always worth the extra work. Thanks Jens, for your suggestions, especially from the semantics point of view. I hope this will be the revival of a conversation that had gone somewhat stale 😁
On July 17, 2009, 9:08 CEST, Jens Oliver Meiert said:
Ciaran, 1) let’s see, I don’t see any indicators yet that microformats will utilize semantics of HTML elements; 2) I don’t refer to vevent and the like, but to location, url, &c., which are more likely to collide; 3) I want to… challenge the microformats community.

Chris, 1) fair enough, although an open process must not mean an excuse for problematic outcomes; 2) dto.; 3) I know both docs, yet I’m not too happy with either one. When it comes to getting involved in the process… I’ve once been, but I’m “picking my own battles.”

Tim, I’m familiar with RDFa, yet the point from my end is probably that I think much more focus should go on keeping things simple and make software do the work. Think Gmail which does a good job detecting appointments in mail to let you add them to your calendar, or search engines in general determining relationships between documents […]. From that angle, microformats are really lazy solutions that move everything to the author, cluttering code at the same time.

Stefan, cool 😊
On July 17, 2009, 9:16 CEST, Régis Kuckaertz said:
The fact that microformats use class names rather than HTML elements is made on purpose, the choice of the right elements should be contextual. Can you please give an example of a microformat using HTML as it could?
On July 21, 2009, 15:45 CEST, Ben Buchanan said:
(1) A counter point would be that keeping the work out of software’s not necessarily a bad thing. The way things are now, the author can implement microformats without much technical overhead. It may be relatively tedious at times but it doesn’t require anything more complex than a flat HTML file.

When I’ve implemented hCards they’ve mostly been in formal contact listings, which already had plenty of markup and needed very little extra to support hCard (it’d be nice if it didn’t need any extra at all of course).

(2) I agree… I think microformat classes should be pseudo namespaced with prefixes. However it’s an idea that hasn’t been able to gain a lot of traction.

(3) Microformats are definitely informal compared with something like the W3C. But the barrier to entry is lower; the barrier to adoption is lower; and if a microformat is bad the impact is most likely to affect adoption of the microformat rather than anything else (whereas I think a bad W3C standard would have a much bigger and broader impact). I suppose the perfect balance is probably somewhere between microformats and the W3C.
On July 22, 2009, 12:01 CEST, Mike said:
For me, the killer is that every so often I come across another puff piece in favour of micro-formats, so I go and look at the official site again to see what progress has been made, and to find something that would be useful, and it isn’t there.
Apart from ‘events’ and ‘contacts’ there doesn’t seem to be any real world use; nor is there any useful software to make use of them. By now I really think that this should be taking off, but I just don’t see it.
On July 23, 2009, 3:25 CEST, Jordan Clark said:
Hi Jens,

I generally agree with most of what you say; however, I have to disagree with you on your optimised hCalendar example.

The thing that I like about microformats is that they can fit content in almost any context; there is no pre-required “layout” or document structure required.

The trouble with semantics “encapsulated in HTML elements” (to borrow Ciaran’s terminology from comment one) is that it locks the developer into a certain document structure; what if a level 3 heading wouldn’t make sense in my current document flow, for instance? Or are you proposing that the parser just picks the first child as summary, the next child as description etc…?

Apart from this point, I completely understand what you mean: microformats can be a bit tedious to code, and do sometimes result in some monstrous-looking markup.
On July 25, 2009, 5:40 CEST, Peter Vigren said:
Generally, I tend to agree that microformats sometimes seem quite flawed. Class names that clash are a big flaw (using them at all is kinda awkward), the abbr issue is one extreme flaw and it generally feels very cluttered with a lot of spans and class attributes (making it feel like a macro format… makes me think of HTML merged with PDF).
However, there is one microformat which I really feel could be something good (or the very least not as bad as the rest); XFN. It is a true _micro_format, requiring only a profile attribute on the head element and using rel (relation) attribute on links that point to people you might have some kind of relation to.
So, generally I tend to agree, feeling most microformats to be too much trouble and too little gain with the only (so far) exception of XFN.
On July 27, 2009, 15:24 CEST, Jens Oliver Meiert said:
Ben, what I mean with respect to 1) is that an author wouldn’t need to do anything if the software would determine the meaning automatically, or at least try to (indicated by the Gmail/Calendar example).

Jordan, as for the hCalendar sample, well, it’s certainly not ideal. When it comes to the heading though, this rather reflects the idea of the microformat allowing any heading to be used as the title (which allows for all flexibility).

Peter, an incomplete reply, too, just a thought—what I always find… interesting about XFN are its maintenance implications. I used to use XFN back in the days but dropped it after I, say, had to update XFN relationships because I got to know someone well enough to say she became a friend, thus not being an acquaintance anymore, or when a co-worker from another office just happened to be met. Assuming you want it to really reflect relationships, XFN can turn quite time-consuming and thus very expensive, especially in a more complex setting.

Thanks all for your comments. My bad being so slow in responding.
On August 1, 2009, 1:26 CEST, Peter Vigren said:
About the maintenance of XFN relationships, I think the website itself states that updating the relationships are in cases not at all required or even that they should not be updated. I think the example was a blog post. Maybe you write about going to see an aquaintance and then use that as rel, later on you marry the “aquaintance”, but since the blog post is a post in history, the relationship is also in history. Then and there, you were only going to visit an aquaintance, no matter what the future holds. This facilitates tracking of relationships during the course of time. And it makes more sense to read a blog post about you dating someone and not see “spouse” as the rel. 😉

But if relationships would be required to be updated, a somewhat simple database could store the relationships and when you link to someone, the appropriate relation is used.

Have a look at the most popular posts, possibly including:

Looking for a way to comment? Comments have been disabled, unfortunately.