W3C home > Mailing lists > Public > www-html@w3.org > October 1999

Re: Acronyms and Abbreviations

From: <Jukka.Korpela@hut.fi>
Date: Fri, 22 Oct 1999 02:48:03 -0400 (EDT)
To: www-html@w3.org
Message-ID: <Pine.OSF.4.10.9910220919460.4966-100000@beta.hut.fi>
On Fri, 22 Oct 1999, Neil Gulati wrote:

> Who cares what the terminology is, what are the tags USED FOR?
> If the issue of pronouncability etc. is dealt with by CSS,
> why have both acronym and abbreviation tags?

The _historical_ background is obviously (though this is just
educated speculation) that Microsoft implemented ACRONYM by accident
(nobody there really thought what "acronym" means, or cared)
and other members of the W3C thought ABBR is a better name for
an element for abbreviations.

So as a compromise*), _both_ were taken into HTML 4.0, but without
even trying to seriously define their meanings, especially as
regards to the difference between them.
*) Compromise: A non-solution selected when there are competing
proposals for solutions; usually combines the drawbacks of all proposed

> Why have either?

The naive answer is: to have something to attach stylistic suggestions to.
But the obvious naive counter-answer is: use SPAN. Then we might note
that we could just as well dispense with almost all elements, using
basically just DIV and SPAN. In fact the difference between DIV and SPAN
is artificial - in the spirit of XML, it's not needed. :-)

Seriously, it can be important structural information that some text
is an abbreviation. It's of course "low level" structure, just as
other text elements (EM, CITE, etc.) are. Yet, in addition to letting
authors conveniently specify a particular presentation style, consistent
use of markup for abbreviations, or for those abbreviations which
"need" to be marked up as such, would _allow_ several strategies:
- browsers displaying abbreviations in some specific style by default
  (e.g. corresponding to one typographic practice where abbreviations
  consisting of capital letters only are displayed in a specific style,
  such as small caps)
- users might specify their preferred style for the display of
- indexing robots and search engines could utilize the information,
  making distinction between, say, CASE as an abbreviation and the
  word case written in all caps.

The structural difference between "abbreviation" and "acronym"
is small and vague, and subject to interpretation of words, as we
have seen in this discussion. Clearly "abbreviation" is better
understood as a general term, so ABBR should be implemented and
ACRONYM should be deprecated. Perhaps a TYPE attribute for ABBR
could be introduced, or a set of "standard" CLASS values for it
could be defined.

I have no idea of how widely authors actually use ACRONYM and ABBR.
Not very much I suppose. ACRONYM is supported by IE only (and only
as something to attach style to) and not widely known, still less used;
ABBR is assumably not supported by any browser in common use. So it's
still not too late to clear things up: deprecate ACRONYM, and rewrite
so that it discusses abbreviations in general, with no attempt to
distinguish between acronyms and other abbreviations.

Yucca, http://www.hut.fi/u/jkorpela/ or http://yucca.hut.fi/yucca.html
Received on Friday, 22 October 1999 05:44:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:51 UTC