On 1 Jul 2008, at 13:28, Scott Reynen wrote:
The difference with ISO dates is we've previously defined them as content; I'm suggesting that's a mistaken definition, as these dates don't function as content in our reference standard iCalendar.
In my view, it's not so much that an ISO dates isn't content per se, it's that it's not content for humans, and in this case, the date content for humans is being published in a different form. In HTML, visible content is for humans, content for machines is hidden.
This makes for a violation of the DRY principal, but it's the same violation we're already making, and it applies not just to datetimes, but also to durations (which has only just been mentioned in this discussion, and is important not to ignore), hCard telephone types, geo co-ordinates, and everything else documented on http://microformats.org/wiki/machine-data .
As an aside, this is why I favoured and have done some initial work into the empty-element-with-title extension to the value-excerption- pattern (which I'm also leading the effort to get properly specified, since it's previously not been). It keeps the machine content in the HTML, can be specified to keep it physical proximity to the human form, but due to the way empty elements are treated, does not expose that content to humans. It does not violate DRY any more than we already do and in relation to the ‘hidden data’ principal, I argue these are exceptional cases _because_ they are DRY violations. We are not hiding information, we're hiding an alternate representation of visible information. (issues page: http://microformats.org/wiki/value-excerption-pattern-issues) .
Much of this same line of discussion applies to the class-name data embedding that Jake and Frances have discussed.
If there's a semantically acceptable solution to this, which doesn't violate any principals, or DRY, or the semantics of HTML, doesn't compromise accessibility or internationalisation, and meets publishers demands for flexibility and doesn't compromise user experience, then that would be fantastic. None of the discussions so far seem to match that.
B _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
