W3C home > Mailing lists > Public > public-html@w3.org > March 2007

Re: Deprecate <acronym>

From: Craig Saila <crsaila@gmail.com>
Date: Mon, 26 Mar 2007 20:47:49 -0400
Message-ID: <cdcda0320703261747r3da1beefpf961c0801f68f3dd@mail.gmail.com>
To: public-html@w3.org

On 3/26/07, Matt Freels wrote:
> I myself like the idea of using class, as it then doesn't have to be
> part of the spec. instead there could be a reccomendation to content
> authors wishing to further divide <abbr> to use class and aural css
> markup (Was this original intent of suggesting using the class
> attribute with <abbr>?) This also has the benefit of being completely
> compatible with the existing spec, for what it's worth.

I've been following these threads quiet closely as the
<abbr>/<acronym> thing is a bit of a personal hobby horse.
Deprecating/removing <acronym> is something I'd strongly endorse for
the reason most have mentioned here (e.g., an acronym is a kind of

In addition, suggesting end users rely on an /optional/ attribute to
further narrow its semantic meaning is sensible (again for the reasons
mentioned, including CSS-level targetting).

However, were we to do this, using "type" makes more sense from the
spec-level, given its acceptable values are traditionally outlined
within the recommendation (whereas authors are encouraged to use
whatever valid value for "class").

Potential values: acronym (e.g., "radar"), initialism (e.g., "HTML"),
and contraction (e.g., "Dr.").
Other values could include: apheresis, aphesis, clipped, and blend or
portmanteau. (Defined:

The only real hurdle I've seen mentioned (aside from debates over what
is/isn't an acronym) is that <abbr> is unsupported by Internet
Explorer prior to version 7. Thankfully HTML 5 is not expected to be a
recommendation for another three years (and there are JavaScript-based
solutions to solve the IE>7 issues).


Craig Saila
Received on Tuesday, 27 March 2007 04:18:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:21:35 UTC