Microformats, Key Flaws

Published on Jul 16, 2009 (updated Feb 5, 2024), filed under development, html, css (feed). (Share this on Mastodon or Bluesky?)

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 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 (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve been working as a technical lead and engineering manager for companies you’ve never heard of and companies you use every day, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), 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. (I value you being critical, interpreting charitably, and giving feedback.)