Re: Abbreviations and Acronyms: [techs] Latest HTML Techniques Draft

On Fri, 12 Dec 2003, David Woolley wrote:

> As you may be gathering, there are variations across Europe in the
> way these terms are defined and also, in England, the general public and
> popular press tend to treat acronym and abbreviation as interchangeable,
> in the same way as they treat virus and bacteria as interchangeable.

Indeed. And as Karl Dubost's quotation indicated (to the extent that I was
able to read with my "MACINTOSH" challenged E-mail client, ehem), there
are other terms to be considered - I find the French definitions
illustrative regarding some _concepts_.

It is quite evident that <abbr> and <acronym> were take into HTML 4
without due analysis and discussion. And it is hopefully getting evident
that the same applies to WAI guidelines.*) There's no reason to make a
universal recommendation on using something that is theoretically obscure
and practically rather useless at present. It's better to use no markup
for abbreviations, acronyms, and whatever, than to use wrong markup,
or completely inconsistent markup, or markup that will inevitably be
misunderstood.
*) And CSS 2 too. Have you ever looked at the rendering suggested for
<abbr> and <acronym> there, in the appendix containing a default style
sheet for HTML 4? What _were_ people thinking when they wrote that?

Regarding XHTML 2, I think this clearly implies that it should have _no_
markup for abbreviations or acronyms, unless very clear semantic
definitions can be virtually agreed on. And names too. Probably the names
of elements for abbreviations should differ from any HTML 4 predecessors
to avoid confusion.

This means, among other things, that the purpose and real meaning of such
markup needs to be analyzed, and probably divided into parts. If we wish
to let authors specify that expressions such as "radar" and "HTML" are
originally abbreviations of longer expressions (and think that it is
insufficient to tell them express that in normal text), then such
etymological remarks should be clearly distinguished from potential need
to explain what some expressions _mean_ - such explanations, when properly
written, seldom take the form of mere expansions. Moreover, there's the
question of _reading_ an expression, which is to be regarded as separate
from the two aspects mentioned.

And regarding the reading hints, or information, which are relevant not
only to speech synthesis but also to human readers who need to speak text
aloud, or just wish to know how they would do that, I'd like to propose a
simple attribute, with role comparable to but not identical with the title
attribute, and accepting any string as its value:
  read="..."
This would be defined as specifying, to the extent that any text can do,
the oral presentation of the textual content of the element. If declared
as a general attribute the same way as title, it could be used with any
element, including span, so we avoid the question what markup element
should be used. Examples:
<span read="World Wide Web">WWW</span>
<span read="mister">Mr.</span>
<span read="ohms">&Omega;</span>

Regarding the expected counterargument that this attribute would be
presentational and should be replaced by the use of (some currently
hypothetical) CSS constructs, I'd like to note that spoken and written
forms of a language exist in parallel. It would be inadequate to treat
their correspondence, which is at times rather irregular, merely as a
matter of treating the written form always as primary and the spoken form
merely as presentation variation in the same sense as font variation.
In fact, since spoken language is historically (and, for the vast majority
of people, in the learning history of an individual, too) the primary form
of a language, if the variation between written and spoken is regarded as
presentational only, then it would be more logical to use
<span class="mister">mister</span>
and use CSS to specify that span.mister be presented as "Mr." in
visual presentation.

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

Received on Friday, 12 December 2003 03:33:19 UTC