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

[Tantek Ç elik]

On 4/28/07 8:04 PM, "Patrick H. Lauke" <redux at splintered.co.uk> wrote:

> Tantek Çelik wrote:
> 
>> 1. Not backwards compatible with existing microformatted non-abbr elements.
> 
>> The problem is that there are already *non* abbr elements out there that
>> contain microformatted information in the element text *and* a title
>> attribute that is informational (e.g. for a tool tip).  That is, they
>> already have a title attribute which is *not* machine readable information,
>> and if you were to *grow* the abbr-title semantic to any-element-title, then
>> you would all of a sudden get a bunch of noise as tooltip text was picked up
>> where the contents of the element were intended.
> 
> Forgive my newness to this, but: could you provide some examples of
> where the generalised title-design-pattern would be problematic?

Here is a simple (theoretical) example (hReview fragment)

<span class="rating" title="Three means fair">3</span>

The author intended "rating" to be "3", not "Three means fair".


> Would this noise be a problem for end users, or just for the tools that
> consume microformats?

Neither directly.

Rather, it would be a problem for the sites who have already published
microformats, because we would be redefining something they are already
doing.

In otherwords, while *currently*, the use of a title attribute on non-abbr
microformatted elements has *NO IMPACT* on the microformat semantics of that
non-abbr element, with the title-design-pattern, those sites that were using
'title' for "advisory information" would suddenly find that that "advisory
information" had been redefined to take the place of a microformat value,
thus very likely breaking their microformatted content.


>> 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".
>> 
>> http://www.w3.org/TR/html401/struct/global.html#h-7.4.3
> 
> We could stretch the semantic meaning of "advisory information" to cover
> machine-readable data (advising the browser/tools), just the same way
> that some of us believe saying that human readable dates are just an
> abbreviation for machine readable ISO dates is a stretch.

A different type of stretch. It stretches what is meant by "advisory", or
who/what is being *advised*, rather than the fact that a precise datetime
coordinate *is* very much a semantic expansion of a shorthand datetime
reference which consists often of only the time, or the day, etc.


>> One important (deliberately designed) aspect of the abbr-title usage is that
>> it specifically limited the extent to which additional semantics were
>> implied to *only* the abbr element, and thus minimized the "damage" that was
>> being done to the title attribute as a whole.
> 
> But this didn't minimize the damage to an entire group of users...those
> using assistive technology.

To be precise, those using assistive technology which has been documented to
have a problem with reading ISO dates.

That being said, I do think we need to solve this problem by solving the
discrete cases (tools) as much as possible.

I've created a wiki page for collecting the list of assistive technologies
that are being used for testing etc. so that we can grow our understanding
over time, please add to it:

 http://microformats.org/wiki/assistive-technology



>> Generalizing this overloading of the title attribute to *any* element seems
>> like a really bad idea from the perspective of minimal change.
>> 
>> 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.
>> 
>> The obvious candidate given the examples used for demonstration is <span>.
> 
> This sounds like a fairly good compromise to me.
> 
>> There may be other elements that can be used for this purpose however, that
>> are used less often than <span>, and semantically meaningless (perhaps
>> purely presentational - thus being fair game for semantic repurposing, like
>> <b> maybe).
> 
> I'd argue that <span> isn't, by its very definition, presentational:

Apparently I was unclear.  What I meant was there may be *other* elements
that are used less often than <span> and that are purely presentational.  I
wasn't saying that <span> was presentational.

> But I'm done arguing :)

We're not arguing on that point :)


>> I don't have a specific proposal here, other than pick one
>> element rather than all, and then I think it gives the other-element-title
>> pattern a better chance.
> 
> I'd go with a span-design-pattern in replacement of the
> abbr-design-pattern.

That wasn't what I was proposing.  I proposed going with a
one-other-element(perhaps span)-title-pattern as a replacement for the
title-design-pattern in these discussions.


> However, does that mean the abbr-design-pattern is
> to be deprecated for anything other than very restricted cases (for
> dates, and then only using the format with dashes and colons that, at a
> stretch, is at least slightly less offensive when read out to end
> users)? And if so, is that not "too big a change", as it would
> effectively break all uses in the wild which up to now have relied on
> the abbr-design-pattern?

Correct that would be too big of a change and breaking existing
microformatted content that egregiously is definitely out of the question.


> Don't get me wrong, I'm not still flying the flag for a general title
> pattern, just wondering if this won't tick off all early adopters of
> microformats (particularly if tools such as Operator are modified not to
> support abbr in favour of span, and/or to flag it as an error if abbr is
> used for anything other than the restricted use scenario)?

It's not an either or situation.

One option (I'm not proposing this, I'm just saying it's an option that
should be part of these discussions) would be to adopt
one-other-element(perhaps span)-title-pattern *in addition to* the abbr
design pattern.

Tantek