Microformats, Key Flaws
Published on July 16, 2009 (⻠February 5, 2024), filed under Development (RSS feed for all categories).
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
, andurl
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 (long: Jens Oliver Meiert), and Iâm a frontend engineering leader and tech author/publisher. Iâve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, Iâm a contributor to several web standards, and I write and review books for OâReilly and Frontend Dogma.
I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Be critical, interpret charitably, and give feedback.)
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 tolocation
,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 asdescription
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.
Read More
Maybe of interest to you, too:
- Next: WDR #3: Optional Tags, Unquoted Attribute Value Syntax
- Previous: XHTML, RIP
- More under Development
- More from 2009
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try WebGlossary.infoâand The Web Development Glossary 3K. With explanations and definitions for thousands of terms of web development, web design, and related fields, building on Wikipedia as well as MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.