You may think that an ISO formatted date with a time is human readable. I don’t.

Also, RTFA. From hAccessibility:

Given a title value of “20070312T1700-06”, JAWS and Window Eyes both try to read an ISO date string never intended to assault human ears:

“Twenty million seventy-thousand three-hundred twelve tee seventeen-hundred dash zero six.”

ogg, mp3.

Yes, Year-Month-Day form dates are more universally comprehensible than their localised counterparts. And if people want to push that upon the world as a better representation they should certainly go out and do so.

‘Teaching people to write dates clearly’ is an honorable goal, but it is most certainly not the goal of Microformats to force that change on anyone. They exist to serve actual publishing practice as well as we can, and publishing is (and will remain) localised. Aesthetics, local comprehension, tradition, a simple matter of publisher taste are all reasons why Y-M-D is not desired in visible (or aural) presentation.

Furthermore, as soon as a date form becomes a date-time form, you do gain nonsense, namely T00:43:00-0800.

rubbish!
“2007-10-05″ is more meaningful to humans than rubbiish like “October 5″ … with the latter how would you know what YEAR they are talking about.

I would call the latter “barely comprehensible” rather than the ISO version.

Would you rather people get the date wrong?

In this case I think I’d want to see the tooltip so that I might be able to see the year!

There is a deeper cultural issue that needs to be looked at here … teaching people to write dates CLEARLY.

So, I’ll try to respond to respond to a few things here. First Bruce, thank you for all the work you’ve done lately (and in the past) helping out with the testing. Hearing about successes in JAWS is a huge boost.

Second, whilst I’ve been the one to take the time to present this new pattern, organise the test, do a lot of recent work and so forth, it’s not entirely ‘my’ proposal. The history of it can be traced through various brainstorming pages and various people’s contributions. Even I haven’t done that to identify individuals, but the point is that credit lies with the community, not with me individually.

Re: Christian Heilmann: The proposed semantics, use of empty span, not proposing using class. A few things:

It is, of course, somewhat subjective. As the wiki page for the current test effort notes, we’re pushing HTML4 into things it wasn’t designed to do (parallel representations of information). So we try to work something out that’s at least somewhat graceful and logical, and critically which doesn’t do any harm.

My reasoning behind a title and span, and in this specific case, reasoning against using class is as follows.

I reason that the machine-form of a date, or co-ordinates or whatever is itself content. You don’t want humans to see it, but it’s still content of the page. You could publish just with the machine-form, it would just be suboptimal to read. Since @title is for content, and we seem to have a cross-browser mechanism through which that title can not be exposed to humans, I find that to be a strong structural reason, and one which matches existing web publishing habits in general (using title, rather than inventing a new syntax elsewhere).
A pattern using @title can, if the author chooses, also expose that data to humans. You can use @value-title on a regular span containing text and have a tool-tip if that makes sense to your publishing situation. It’s flexible.
The title element ends up as a sibling to the human form. Again, that structure makes a lot of logical sense to me that the two forms are together as siblings in the DOM tree.

Regarding @class. Christian’s comment that ‘Class attributes are meant to store machine information according to the W3C specs’ is completely incorrect, and is a suggestion that comes up over and over again. So:

The HTML4 spec says, in section 7.5.2 on id and class attributes:

“The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes.”

Below, it says that class may be used for stylesheet selectors, and ‘For general purpose processing by user agents.’

That ‘general purpose’ statement is wildly and regularly misinterpreted as allowing class to contain arbitrary data, even though that use contradicts the ‘belong to these classes’ specification. A data value is not a classification. Further clarifying this, under the spec for the id attribute in the same section above, ‘general purpose processing’ is defined more fully:

‘For general purpose processing by user agents (e.g. for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.).’

Thus, @class is for classifying elements and for identifying fields (which is exactly what microformats does with it). Those things taken together, I don’t see how the spec can be read as permitting data itself to be valid within the class attribute.

Even if you disagree with my assertion that the ‘machine form’ is content, @class is still an invalid place to stick it.

Jared: Bruce already covered this in the article, but the data- attributes in HTML5 are explicitly and clearly defined as not for use by microformats: ‘Specifications intended for user agents must not define these attributes to have any meaningful values.’