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

Re: Deprecate <acronym>

From: Olivier GENDRIN <olivier.gendrin@gmail.com>
Date: Fri, 30 Mar 2007 14:17:30 +0200
Message-ID: <e2c275120703300517y4ca8a947tc19092f2b5e6aa07@mail.gmail.com>
To: public-html@w3.org

On 3/27/07, Craig Saila <crsaila@gmail.com> wrote:
> 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
> abbreviation).
>
> 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).

I agree globaly with Craig : if we decide to use in tag for shorten
strings, we have to indicate the type of shorten to the UA. And we
can't rely on class/CSS for this job, because :
- name classes arn't (hopefully) normalised. I can decide to indicate
intialism by 'init', but someone else will use the same class for
somthing totaly different, and have an 'initialism' class for
initialism.
- and some UA allow users to override the CSS. So users will have to
build a CSS for *each* site they visit in order to keep their pref',
according to the classes choises made by the site maker.

CSS are made for presentation issues, while pronociation aren't
presentation, but are strongly linked to the information that we want
to give.

> 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:
> <http://dictionary.reference.com/help/faq/language/t08.html>)

Whooa. We will have as many types as display... Quite logical...
Received on Friday, 30 March 2007 12:17:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 30 March 2007 12:17:47 GMT