Jim wrote:
Span seems a more pragmatic choice to me, since title on <span>
supplements the enclosed text, whereas title on <abbr> replaces the
enclosed text. As someone else mentioned, for a lot of these cases
we want to annotate a piece of text with computer-parsable
information.
I agree that there are problems (both semantic and—from the angle of
assistive technology—possibly practical) associated with using ABBR.
But I really don't understand this obsession with SPAN. Why would
SPAN be any more or less preferable to any other element?
I think the crux of this matter is that the ABBR design pattern is
one of the few times when using a microformat mandates what element
an author should use.
In hCard, for example, all of the following are fine:
<span class="fn">Jeremy Keith</span>
<em class="fn">Jeremy Keith</em>
<div class="fn">Jeremy Keith</div>
<cite class="fn">Jeremy Keith</cite>
...and so on. You get the picture. The author gets to decide which
element to use based on the context. A good author will choose the
best (most semantically meaningful) element for the task at hand.
Sometimes that might be SPAN but not always.
For datetimes, this semantic decision is only in the hands of the
author if they choose to display the datetimes as text contained by
opening and closing tags. All of these are, from the perspective of
the hCalendar spec, fine:
<span class="dtstart">2007-12-16T16:20:00</span>
<em class="dtstart">2007-12-16T16:20:00</em>
<div class="dtstart">2007-12-16T16:20:00</div>
The problem is that, if the author wants to use a design pattern that
doesn't display this data between tags, the only option is to use the
ABBR design pattern:
<abbr class="dtstart" title="2007-12-16T16:20:00">
...and that's when you run into all the problems we've been
discussing. There are potentially problems with screenreaders (test
results are still needed firm up these issues) but, more
fundamentally, there's the semantic issue, as Ben said:
This doesn't actually need to have any concern with accessibility,
or assistive technology tools. Frankly, the difficulty in getting
solid tests from such tools makes that line of argument less
attractive in itself. But what has to be a fundamental baseline in
our implementation of optimisation patterns in microformats is the
HTML specification we are building on top of.
If a design pattern is going to *mandate* that authors must use a
particular element, then the semantic meaning of that element needs
to be pretty solid. That doesn't seem to be the case with the ABBR
design pattern, as evidenced by the discussion here and, more
importantly, as is outlined in the HTML spec.
In my opinion, this matter might be best resolved by giving the
choice back to the author. Allow the author to decide what element is
semantically best suited for the datetime pattern, just as the author
is allowed to decide what element is semantically best suited for any
other microformat class name.
But...
If we just swap out ABBR for SPAN, we're not solving anything. The
SPAN element *might* be the right element to use for a datetime, or
another element might be better... it all depends on the context—
something that only the author will be aware of.
So when we're talking about alternatives to the ABBR design pattern,
can we please stop just talking about SPAN? Surely what we're really
talking about is allowing the design pattern to be expanded to any
element (not just ABBR), at the author's discretion.
There's already confusion out there: some people have looked at the
wiki and mistakenly jumped to the conclusion that authors must use
SPANs and DIVs to create microformats because those are the elements
used in the examples. Let's not turn those fears into reality by
seriously suggesting that authors must use the SPAN element if they
want to employ the datetime design pattern.
Can we agree that what we are discussing is opening up the datetime
pattern to elements other than ABBR, not simply swapping ABBR for SPAN?
I'd be willing to consider a SPAN design pattern if it had any
semantic merit but considering that SPAN is effectively lacking in
any semantic value, I don't see how a SPAN design pattern would be
any better than a DIV design pattern, a P design pattern, a Q design
pattern or a CITE design pattern.
In short, I don't think we should be telling authors what elements to
use. That's what got us into hot water with ABBR; I don't want to see
the same mistake repeated again. The fact that microformats allow
authors to choose the most semantically meaningful elements
(according to context) is one of the great strengths of microformats,
in my opinion.
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
