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

[Tantek Ç elik]

Jeremy,

While certainly I am swayed by many of your well reasoned arguments, I must
point out one particular flaw:


1. Not backwards compatible with existing microformatted non-abbr elements.


On 4/28/07 2:12 PM, "Jeremy Keith" <jeremy at adactio.com> wrote:

> I'd also like to point out one of the beauties of the proposed title-
> design-pattern: it's completely backwards compatible with the abbr-
> design-pattern. The abbr-design-pattern uses the title attribute of a
> *specific* element: the title-design-pattern uses the title attribute
> of *any* element.

This is not entirely correct.  Being backward compatible with microformatted
abbr elements is only *part* of the backward compatibility problem.

There other part is being backward compatible with existing microformatted
non-abbr elements, which is where the problem is.

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.

I've seen these in numerous examples in the wild, and if there is dispute on
the existence thereof, can document as necessary.



2. Too big of a change.

As illustrated by the backward compatibility case above, this may be too big
of a change.

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

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.

Even then I hesitated before proposing it, and only after exhausting what I
thought were perhaps other workable alternatives (e.g. object, and yes,
Safari's marketshare was significant enough to cause Yahoo to pull
object-include-pattern support, so others made that distinction as well).

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

And though it may seem odd that I'm simultaneously arguing against the
proposed title-design-pattern and attempting to improve it, even if I am
against a particular proposal, I would much rather attempt to improve it in
good faith, for the benefit of having the best possible proposals be
discussed, than not.

Thanks,

Tantek