[uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change

[Jeremy Keith]

Tantek said:
> 1. Not backwards compatible with existing microformatted non-abbr  
> elements.
and
> Here is a simple (theoretical) example (hReview fragment)
>
> <span class="rating" title="Three means fair">3</span>

Yes, but the proposal is to limit the title-design-pattern to  
*specific* classes

As James said:
> Any element, but only on specific Microformat classes, each of  
> which has expected RegEx-matchable values. DTSTART, DTEND,  
> DURATION, RDATE, RRULE expect values defined in RFC 2445. TYPE and  
> GEO expect values defined in RFC 2426. This would eliminate the  
> ambiguity of title-or-contents.

These kind of rules already exist in microformats. Take the url value  
in hCard, for example. Parsers look for the value in the href  
attribute, not between the tags. In that case there is a simple rule  
for parsers to obey. By restricting the title-design-pattern to a  
limited number of values, we can provide equally straightforward  
rules for parsers.

Now... there's also the issue of multiple class names and how parsers  
should handle the situation with one of the classes that James lists  
*plus* another class.

Here's an example from a (theoretical) vevent:

<span class="dtstart summary" title="2007-05-01">May Day</span>

According to the proposed title-design-pattern, the value for dtstart  
is extracted from the title attribute while the value of summary is  
extracted from between the tags.

dtstart: 2007-05-01
summary: May Day

Limiting the title-design-pattern to specific classes like this would  
counter the second argument:
> 2. Too big of a change.

In a way, what's being proposed here is an inverted version of  
Tantek's suggestion:
> If on the other hand, you were to simply extend the abbr-title  
> pattern to
> *one* other element (rather than *all* non-abbr elements), then the
> additional damage would be less than were you to extend it to all  
> elements.

Rather than limit the title-design-pattern to one (other) element, it  
makes more sense to me to limit the number of scenarios where the  
title-design-pattern applies at all (specifically: datetime and geo  
information).

Defining a specific element to use feels restrictive to me. We've  
already run into plenty of trouble with the abbr element from people,  
quite fairly, questioning the semantic appropriateness. For me, one  
of the great strengths of microformats is that they generally don't  
mandate what elements should be used.

There's already a misconception out there that microformats "demand"  
the use of superfluous divs and spans (a misconception probably  
derived from the examples and specs and something I hope to address  
with some tutorials at some stage). If we introduce a design pattern  
that mandates the use of a specific element, I feel that might place  
an unnecessary burden on publishers.

I realise that introducing the title-design-pattern for a limited  
number of classes introduces a burden for parsers but I'm okay with  
that. :-)
Most importantly, the existing practice of encoding datetime and geo  
information in the title attribute of an abbr element is entirely  
compatible with the proposed title-design-pattern (restricted to  
these specific classes).

To give an example of why I wouldn't want to be restricted to a  
specific element (and again, this is purely theoretical so take it  
with a huge pinch of salt), I might want to publish:

<h1 class="dtstart summary" title="2007-05-01">May Day</h1>

Rather than being forced to nest elements:

<h1 class="summary"><span class="dtstart" title="2007-05-01">May Day</ 
span></h1>

or:

<h1><span class="dtstart title="2007-05-01"><span class="summary">May  
Day</span></span></h1>


Now, with all that said...

If we were to find an existing HTML element that was semantically  
suited to encoding datetime and/or geo information *and* didn't cause  
problems with assistive technology, then I would jump all over it and  
agree wholeheartedly that the title-design-pattern should be  
restricted to that particular element. But I don't believe such an  
element exists.

In the absence of such an element, I'm in favour of allowing this  
pattern on any element. But I'm well aware of the problem:
> The other point that has been made that the title attribute on HTML4
> elements in general (excluding abbr, acronym) is meant for the  
> author to
> provide "advisory information about the element".

Semantically, we're somewhat screwed. We're damned if we use the abbr  
element (stretching the definition of abbreviation and causing  
problems for screen readers) and we're damned if we use any other  
element (abusing the title attribute to hold information that is not  
advisory information).

So the problem becomes one of damage control.

Tantek's proposed damage limitation is to open up the abbr-design- 
pattern to just one other element.

James and I want to open up the pattern to any element but limit the  
damage by restricting the number of classes the pattern applies to.

But if the consensus is that Tantek's proposed damage limitation  
makes the most sense, I will quite happily go along with that.

Bye,

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/