However, I think you miss an important point when you dismiss microformats as unnecessary. They are usable in many contexts where generation of a separate format is difficult or impossible. For example, I could write something like:

<p class="vevent">Hi everyone. I'm having a <span class="summary">party</span> on <abbr class="dtstart" title="20070704">Independence Day</abbr>!</p>

…and it will at once be usable both as straight HTML and as structured hCalendar data. Because it’s straight HTML, I can put it anywhere — including in an RSS feed description, or in my LiveJournal — and it is immediately legible. With an format such as xCal or iCal, I would have to create a separate file in a completely different format, which I may not have the time, inclination, or ability to do. Besides, why generate the same data twice? (Yes, I know, a developer would translate into the required format on the fly, but microformats are largely aimed at non-developers, and the whole idea is to make them easy to use. Besides, even though I may know how to generate an iCal file, how do I make one automatically available, say, as part of my LiveJournal, where I don’t have access to install a server-side script? hCal obviates this problem.)

Sure, a programmatic XML solution will be more comprehensive and potentially less ugly. But it’s also out of the realm of more users. I like the microformat idea because it opens up the semantic possibilities of the Web to non-developers.

Everybody is talking about how there needs to be a showcase application for microformats. Something that helps people understand the power of it. There’s also all of this talk of greasemonkey and ajax. Well, here is an awesome idea for

You seem to be saying that microformats are being supported because applications treat them as they do any other XHTML…if that is support then what is it called when applications do something useful with them? Fully-supported?

My view, upon re-reading my own article and others, is that microformats are an unnecessary intermediary step. We’ve got applications will full XML support, why not just write a specialized format that doesn’t become part of XHTML? Just like RSS, OPML, and Google sitemaps? The whole power of XML is specialized uses (via specialized tags), so I don’t really buy the “solve a particular problem” reasoning that microformats push. That’s exactly what these other three are examples of, specialized formats for specialized problems.

You don’t need a mozilla plug-in or Greasemonkey script to style hcards as you would like. Try a user style sheet.

The promise of microformats, as Eric Meyer points out, is a potential promise. “They’re not supported yet” is an interesting argument, and I see what you mean, but of course they are supported. They are simply XHTML with enhanced semantics. They are supported inherently within CSS, Javascript and any other technology that walks alongside XHTML.

You can go away and write a little Javascript app to utilise hcard today. Not many people are doing it yet, but that doesn’t mean they’re not supported.

Thanks for the link. This is a good, thoughtful piece, and I will likely respond more fully in a post of my own. There’s a point that strikes me that I would, however, just like to dash off now. It regards what I think is a general misperception, even in the microformats community, about the role of microformats with respect to RSS.

RSS (and atom another xml syndication format) is really just a notification format with room for certain types of predetermined metadata like links, categories, authors, and most germanely the description. The description element contains “the message” and is generally left to be constructed as the author (or the author’s software) sees fit.

One might argue, however, that the relatively unstructured description or message element is the most important element. The reader has signed up for the notifications in order to receive the message, not just metadata about the message.

Recognizing this key point, many lately have come to structuring the description element in their syndication feeds with html markup because they want their message to visually convey meaning. Witness your very own RSS feed. An xhtml microformat just carries this further by adding semantics to the message element without requiring the invention of a whole new markup than what the author is already using. That way, machines will be able to process the message more effectively and produce aggregations like technorati or rubhub or EVDB.

In spite of the examples I just gave, you are right to point out that there need to be more services that take advantage of message semantics for microformats to become immediately compelling. Based on private discussions I have had, expect to see more of those.

To come back to where I started, it is incorrect, in my view, to really consider microformats as an alternative to RSS. Microformats are actually a complement that fulfills a very important role in making the messages conveyed more easily processed by machines. As a bridge between man and machine for the most important part of the data payload, microformats are Web 2.0.

Being a Firefox devotee, for me microfotrmats would work very well if there was a Mozilla extension or Greasemonkey script that allowed me to configure how I wanted hCals and the like displayed, the advantage being that with the right extension I could tailor those displays to my own specifications instead of relying on what the browser vendors think would be a good way for me to see those microcontent offerings. That, of course, leaves the other 85% of browser users without a great solution (or really any at all).

The other (obvious?) advantage for designers is the ability to style that content in a consistent way no matter where the content comes from. That opens the door for some really great re-aggregation schemes, like a Technorati-like site for reviews or events. Perhaps these are already out there as we speak.