W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2005

[whatwg] [WA1] Web Apps 1.0: dfn and homonyms and the title attribute

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 06 Jul 2005 05:49:41 -0400
Message-ID: <42CBA935.3090006@inkedblade.net>
Ian Hickson wrote:
> On Tue, 5 Jul 2005, fantasai wrote:
>>You mean, like
>>  <dfn title="CSS property">
>>Wouldn't that cause trouble for an automatic indexer? The term should
>>be filed under 'property', not 'CSS'.
> So make the title "property, CSS".
> Or have the indexer do the usual thing, and reverse the word order.

Reversing word order /sometimes/ works for English. It doesn't work
for multi-word terms like "World Wide Web Consortium". It also doesn't
work for languages like French. As for "property, CSS", that is not
the term being defined. The term is either "property" or "CSS property"
to be more precise.

>>>This is done all over the place in the HTML5 spec, fwiw.
>># <dfn id="updateeverything"
>>That 'title' is not a human-targetted string, Ian.
> Indeed.

Give me a good reason why the 'title' attribute on <dfn> should not
be a human-targetted string like it is on every other element. Please
also explain why the 'title' given here is not the actual term being
defined but rather an arbitrary (human-readable but nonetheless) 
computer-targetted string that you are associating with the term for
cross-referencing purposes.

The use of computer-targetted strings in 'title' for cross-referencing
forces the span, abbr, code, var, samp, and i elements to use non-human-
targetted strings in /their/ title attributes, despite the attribute
being defined as text for humans to read. What makes this scheme, which
subverts the purpose of the 'title' attribute on so many elements, so
attractive compared to other solutions you have considered?

Received on Wednesday, 6 July 2005 02:49:41 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:41 UTC