Tantek wrote:
I concur with Jeremy - this is a really bad idea.
I think we can all agree that the addition of an extra class for the
benefit of parsers "smells" bad so we can probably ditch that
suggestion.
In addition, using span title is less semantic than abbr title thus
it is
undesirable.
Ah, now here's where we differ.
I agree that it is technically less semantic. A title attribute on an
abbr element means something different to a title attribute on any
other element. I agree that storing machine-readable data in the
title attribute of an arbitrary element is less than ideal...
although storing machine-readable data in the title attribute of an
abbr element has always felt more than a little shady anyway.
To be frank - the blog post on hAccessibility WaSP was seriously
flawed.
It's true that the example was extreme--including timezone info and
leaving out dashes and colons--but the fundamental point was still a
good one.
I for one have always tried to push things (browsers, content)
towards at
least being accessibility-friendly, and I still think that's a good
policy.
However, I'm against contorting microformats because of bugs or
suboptimal
behaviors in <1% marketshare browsers.
Normally I would agree with you here. But the situation with screen
readers is somewhat different. We're not talking about a regular
browser here: if someone is using a sub-optimal or outdated web
browser and they don't get the full benefits, then that's something
that can be brushed over but for a blind person using the most up-to-
date technology available to have to put up with an illegible piece
of data isn't acceptable. In this particular case, the market share
numbers are--to my mind--irrelevant.
I think there needs to be a balance.
I agree completely. And I find the title-design-pattern to be a good
compromise.
It's true that it is semantically less correct than the abbr-design-
pattern but given that pattern's dubious grounding, it's probably
more accurate to refer to the title-design-pattern as "slightly more
semantically dubious" rather than "worse."
In addition I think this is a case where a little bit of pain now
with abbr
and some tools actually opens up the potential for *much* better
accessibility/usability tools (once UAs actually recognize ISO
dates as such
and can speak/rewrite them for a user's datetime/language/locality
preferences). I for one think this tradeoff is more than reasonable.
If we were talking about anybody other than screen reader
manufacturers, I would agree with you. But history has shown us that
these people, frankly, don't give a shit.
I've made it very clear (on the WaSP blog post and elsewhere) that
microformats represent a huge opportunity for screen reader
manufacturers. Derek Featherstone gave me goose bumps at the Web
Directions conference in Sydney last September when he mocked up a
demo of what it might sound like for a screen reader not just to
announce the number of links and headings on a page but also "There
are X number of contacts and Y number of events on this page."
Inspiring stuff! But... in the here and now we have to deal with the
current (craptacular) technology that screen reader users have no
choice but to use.
In this instance, we could stick by our semantic guns and say that
the more semantically correct solution (the title attribute on abbr)
is preferable to a slightly less semantic solution (the title
attribute on any other element). But I strongly feel that, in this
particular case, that would be a grave mistake.
The theory of the abbr-design-pattern is pretty good. The
practicalities are problematic.
The theory of the title-design-pattern is problematic. The
practicalities are pretty good.
So what do we choose?
I firmly believe that the strength of microformats lies in their
*practical* value. Microformats have always been a here-and-now
technology rather than a utopian idea for some future Semantic Web
(see: RDF and other noble but failed W3C technologies).
It's a somewhat bitter pill to swallow but I believe that we need to
balance the practical and the semantic angles to embedding machine-
readable data inside markup and come down on the side of practicalities.
Therefore, I fully support the title-design-pattern. I don't believe
it will be a slippery slope that leads to any semantic watering-down
of microformats. I believe it's a necessary step to take to deal with
the situation on the ground with screenreaders.
I'd also like to point out one of the beauties of the proposed title-
design-pattern: it's completely backwards compatible with the abbr-
design-pattern. The abbr-design-pattern uses the title attribute of a
*specific* element: the title-design-pattern uses the title attribute
of *any* element. abbr is an element therefore the title-design-
pattern still applies to the abbr-design-pattern. Already-implemented
vevents will still work using the title-design-pattern. It may be
that some parsers may have to broaden their range to search for
datetimes in the title attribute of any elements but I wouldn't be
surprised if current parsers are already being liberal in what they
accept.
I'd be interested in hearing if anyone else feels as strongly as I do
that the title-design-pattern is something that should codified as
soon as possible. I'd be even more interested in hearing if there's
anybody, like Tantek, who feels that it's a bad idea... or to be more
accurate, who feels that the practical benefits don't outweigh the
semantic purity.
Bye,
Jeremy
--
Jeremy Keith
a d a c t i o
http://adactio.com/
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
