Microformats, Key Flaws
Post from July 16, 2009 (↻ August 11, 2014), reflecting Jens the Web Developer.
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 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
urlare likely to be used by authors in other contexts. That authors can style 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 does truly have 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>
vevent as the pseudo-namespace, and remove the
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 still remains).
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.
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).
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.
@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: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?
(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.
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
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 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, eventually including: