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

[Patrick H. Lauke]

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?

Would this noise be a problem for end users, or just for the tools that 
consume microformats? And, if it's the latter, would it not be easier to 
fix these tools rather than expect assistive technology vendors to amend 
their products because of this group's interpretation of what title on 
an abbreviation can contain and what the AT should or shouldn't do when 
it encounters machine-readable data (e.g. reinterpret it back into 
human-readable form, or omit it completely, to protect the end user from 
hearing gibberish)?

> 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.

> 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.

> 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:

"The DIV and SPAN elements, in conjunction with the id and class 
attributes, offer a *generic mechanism for adding structure to documents*."
http://www.w3.org/TR/html401/struct/global.html#h-7.5.4

Also, the fact that no browser gives them any default presentation would 
seem to support this.

But I'm done arguing :)

> 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. 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?

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)?

P
-- 
Patrick H. Lauke
______________________________________________________________
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com
______________________________________________________________
Co-lead, Web Standards Project (WaSP) Accessibility Task Force
http://webstandards.org/
______________________________________________________________
Take it to the streets ... join the WaSP Street Team
http://streetteam.webstandards.org/
______________________________________________________________