RE: abbreviation title within a link: howto?

At 02:36 AM 2002-05-22, Jukka Korpela wrote:

>Hence, before encourageing authors into using markup for abbreviations and
>acronyms, quite a lot of work with _defining_ them needs to be done, and
>this involves considering how the information in the markup would actually
>be used and how the uses might conflict. There's little hope before the
>specifications even define <abbr> and <acronym> reasonably with respect to
>each other; cf. to the analysis at
>http://www.benmeadowcroft.com/webdev/articles/abbr-vs-acronym.shtml

Good summary, good review of the topic.

One small wrinkle:  

It is possible to do all that for a superclass that subsumes both of these.  There doesn't need to be a clear distinction between them to have adequately defined constraints on what will happen with either.

But it could help.

One operational distinction that would seem to matter is a difference in "TTS mode hint" that is 'speak' in one case and 'spell' in another case.

Al

>Joe Clark wrote:
>
>> I wouldn't bother. <abbr> and <acronym>, which are what you're
>> really getting at here, are useful only for *unfamiliar*
>> acronyms, - -
>
>On the practical side, I agree with your basic view. In addition to problems
>with implementations, <abbr> and <acronym> markup was never _defined_
>semantically in a useful way that could form the basis for making use of the
>markup in various programs, including browsers. There's little point in
>trying to persuade authors into using markup that lacks well-defined meaning
>and that has unpredictable results.
>
>On the forward-looking side, or perhaps utopistically, I think that markup
>for familiar acronyms could be very useful, for accessibility and other
>purposes.
>
>> If you really, really insisted on doing this, you should use
>> <acronym title="learning disability">LD</acronym> inside <a></a>.
>> Presumably that would validate.
>
>Well, yes, it would, and nested <a> elements would not, in pre-XHTML HTML.
>(The "X" means, among other things, less expressive metalanguage, so that
>the prohibition to nest <a> elements needs to be said in prose for XHTML.)
>No, I don't see any particular reason why the prohibition to nest <a>
>elements was taken into HTML, but I digress.
>
>> One suspects that every reader of your page will know what "LD" means.
>
>Maybe, but some of them might not _remember_ it easily.
>
>Besides, a "reader" of the page could be an indexing robot, a speech-based
>browser, or an automatic translation program. Suppose I know English just a
>little and would benefit even from a relatively poor translation. (Lack of
>linguistic capabilities is a form of disability, in a sense.) If
>abbreviations were marked up, with their expansions, even very simple
>translation technology could produce better results in many cases; in this
>example, it could behave as if the expansion appeared in place of the
>abbreviation. Naturally, such strategy would easily lead into disaster too:
>translating "World Wide Web" word by word (and perhaps then forming an
>initialism from them!) would produce something rather incomprehensible.
>
>Hence, before encourageing authors into using markup for abbreviations and
>acronyms, quite a lot of work with _defining_ them needs to be done, and
>this involves considering how the information in the markup would actually
>be used and how the uses might conflict. There's little hope before the
>specifications even define <abbr> and <acronym> reasonably with respect to
>each other; cf. to the analysis at
>http://www.benmeadowcroft.com/webdev/articles/abbr-vs-acronym.shtml
>
>-- 
>Jukka Korpela
>TIEKE Tietoyhteiskunnan kehittämiskeskus ry
>Finnish Information Society Development Centre 
>Salomonkatu 17 A, 10th floor, FIN - 00100 HELSINKI, FINLAND
>Phone: +358 9 4763 0397 Fax: +358 9 4763 0399 
>http://www.tieke.fi  jukka.korpela@tieke.fi

Received on Wednesday, 22 May 2002 08:16:32 UTC