[uf-discuss] Re: Precise Expansion Patterns

Jeremy Keith jeremy at adactio.com
Sun Dec 16 09:30:38 PST 2007

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.


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.



Jeremy Keith

a d a c t i o


More information about the microformats-discuss mailing list