W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2000


From: Gregory J. Rosmaita <unagi69@concentric.net>
Date: Tue, 22 Feb 2000 20:27:54 -0500
Message-Id: <>
To: pjenkins@us.ibm.com
Cc: WAI Interest Group Emailing List <w3c-wai-ig@w3.org>
aloha, phil!

i'm extremely troubled when i hear representatives of developers say things 
such as:

If nothing does or nothing should happen with ABBR, then why mark it up?

the quote it isn't supported so why do it unquote approach is the very 
mind-set that the WAI exists to change...  when you advocate ignoring any 
markup which isn't currently supported by a quote mainstream unquote user 
agent, you are throwing the baby out with the bathwater...

why should we forego using markup that isn't supported in mainstream user 
agents?  by such logic, no one should bother using LONGDESC, SCOPE, AXIS, 
and any of the other elements and attributes that are defined for HTML 4x, 
but which are either supported spottily, incompletely, inconsistently, or 
not at all...

your point about the application of stylesheets to demarcate (visually or 
aurally) that (a) this is an abbreviation, (b) this is an acronym, and (c) 
that an expansion is available, is, however, well taken, and is a 
compelling argument against jettisoning one or the other...

one might --  based on a visual or aural stylesheet, or via the use of 
inline pseudo-elements -- care to expand or not expand text enclosed in 
either the ACRONYM or ABBR tags, or allow one's user agent or adaptive 
technology to do so either by default or when queried, or to compile a list 
of abbreviations and/or acronyms and their expansions, but in order to 
perform (or have one's software) perform any one (or any combination) of 
the actions listed above, one first needs to _know_ that expansions have 
been defined for the document currently being rendered...

finally, what constitutes an abbreviation and what constitutes an acronym 
_is_ germane to the discussion, as they are not only very different things, 
but pose different sets of problems for different groups of users...  the 
number of potential users affected by use of ACRONYM and ABBR is quite 
large, as they not only enhance accessibility, but are aids to non-native 
speakers of the natural language declared for the page being rendered, as 
well as general usability aids...


At 02:17 PM 2/22/00 -0600, Phil wrote:
>Emmanuelle wrote:
> >I believe that none of both should be eliminated. In Spanish the distinction
> >between acronym and abbreviation is very clear. ...
> >
> >... in Internet Explorer when in a page there is an
> >identified acronym as such, if the pointer of the mouse is placed on him its
> >definition it can be read, that which doesn't happen with the abbreviations.
> >And this is logical because the abbreviations are of common use in a
> >language, ...
>If nothing does or nothing should happen with ABBR, then why mark it up?
>If the user agent should expand it [at the users request], just like
>ACRONYM, then why have both? Perhaps it doesn't matter if both are treated
>the same by being expanded, even thought to some they are different things.
>If your point is that they should be treated differently, then how?  If the
>difference is that one should be expanded and the other not, then we are
>back to my argument that it should not be marked-up. I don't know of any
>ELEMENTS that are treated the same, at least none that haven't been
>deprecated,  Many deprecated duplicate elements are still supported anyway,
>just no guarantees.
>Since user agent manufactures will maintain some backward compatibility and
>continue to handle both - who cares if we deprecate one?  We're not solving
>a problem by deprecating one or the other are we?
>I'm O.K. with having both even though they should / will be expanded the
>same by compliant browsers.
>What ABBR and ACRONYM - are - is not important in this context.  How they
>are specified to be treated is the important part.  I might want a list of
>them, I might want them expanded in different languages, I might want them
>highlighted per my style sheet, etc.  The user agent should let me do all
>these things to both of them.  Is there an argument that they should in
>fact be treated inherently different by the user agent?
>Phill Jenkins

He that lives on Hope, dies farting
      -- Benjamin Franklin, Poor Richard's Almanack, 1763
Gregory J. Rosmaita <unagi69@concentric.net>
    WebMaster and Minister of Propaganda, VICUG NYC
Received on Tuesday, 22 February 2000 20:19:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:07 UTC