It pains me to speak ill of the microformats community, because I highly regard both the concept of microformats and the effort they have put into specifying them. However, there’s no escaping the simple fact that using the <abbr> element in this context is beyond inappropriate.

1. It disregards a recommendation in the HTML specification for the use of the title attribute in abbreviations:
   

   The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression.

   The ISO date is emphatically not a “full or expanded form” of the actual English date. If anything, it is the opposite.

2. It compromises one of the principles of microformats. By obeying the letter of the law (“visible data is much better for humans than invisible metadata”), it violates the spirit: “design for humans first, machines second[.]” ISO dates are predominantly consumed by machines, not humans.
3. Despite Tantek’s protest above, no data is actually being hidden from human beings—who are, after all, the audience that matters—nor does rendering the ISO date visible confer any informational advantage on the human being who is reading your page. Its presence in your document is purely a convenience to mechanical parsers, not your readers (as evidenced by the above discussion about the programmatic difficulties of localisation); to them, the class attribute is no less “visible” than any other.
4. Finally, it neglects the requirements of certain visually-impaired users by presenting them with an incomprehensible string of digits, letters and symbols in lieu of sensible information:
   

   Instead of getting the human friendly message of “half a minute”, a screen reader user with expanded abbreviations configured would get something like “two thousand and eight dash zero four dash twenty six tee six colon fifty two colon twenty plus one o’clock”. Not a particularly friendly or intuitive expansion. In fact, it is materially incorrect. The time stated is 06:52, not one o’clock.

   This happens when the screen reader’s verbosity settings are such that abbreviation titles are read aloud by default. The justification provided for permitting this disorienting scenario is that most screen reader users do not change their settings. However, such users do exist, and their expectations are reasonable; without representative statistics demonstrating that their numbers are negligible this statement is insufficiently compelling to allay my concerns.

   Again, referring to my second point, this sort of improvidence seems to contradict the basic principles of microformats.

Something you said earlier, Alistair, reflects how I initially felt about this issue:

Tantek’s a very clever guy and having an internal inconsistency like that is unlikely. […] I’m more inclined to think that there is a facet of [Tantek's] argument I’m missing.

Indeed, Tantek is a clever fellow, and his opinion will be firmly based on justifiable premises. However, microformats are a subtle concept—transparently transcending the semantic limitations of HTML without compromising the specification or real-world requirements—and what we are discussing is a particularly tricky issue. It is distinctly possible that there are no solutions which unambiguously satisfy all criteria.

Even if there is no panacea to these conflicting requirements, I remain strongly opposed to the abbr design pattern. It is not ideal semantically; it is not ideal in principle; it is not ideal to users; and it is not ideal for accessibility. The class attribute is not an ideal solution in principle, but it is semantically justifiable and does not compromise usability or accessibility in any way whatsoever.\

But still, the only solution the makes any sense to me is using class attributes. I see no logical reason not to use them, yet ‘vehement’ opposition stands…

What would clearly be wrong (IMO at least), is making something not human friendly human viewable.

If you can cover the languages where people can automate the process of producing HTML content, that is more than enough.

That other proposals have not (yet) been accepted does not mean that they are not workable.

I assume the proposals you mention haven’t been accepted, otherwise we wouldn’t be here.

That’s because I can’t prove a negative. If you think you can prove that it can be done, feel free. You could start by pointing to the PHP code which does it in the easy direction, for *every* language…

Why stick to “one thing at a time”, when there are already proposals which woudl fix this issue in all cases?

It does work the other way around for PHP, which must in some form output suitable formats for different languages.

Therefore a parser could detect the language (nearest lang attribute set up the DOM tree), and use the rules associated with that language.

The other examples I haven’t looked into, but one thing at a time…

And it *still* doesn’t solve the coordinates and duration examples.

(The hAudio example in my last post was supposed to be [abbr class="duration" title ="PT3M23S"]3 minutes and 23 seconds[/abbr])

Surely what ever process goes from computer readable to human readable (e.g. today “d F o” = “24 July 2008″), can recognise that format and reverse it?

And if that is possible, surely the same forwards rules can be reversed for internationalisation purposes?

How is a parser writer to understand a microformat in a language, or even character set, with which they’re not familiar?

How will it solve the issue of, say, exposed machine-readable coordinates, or hAudio’s duration: 3 minutes and 23 seconds ?