[whatwg] Feeedback on <dfn>, <abbr>, and other elements related to cross-references
contact at nickshanks.com
Mon Apr 21 06:54:05 PDT 2008
Ian, I think you have made a mistake.
We need to go through this more methodically before making a decision.
I hope the following aids matters.
First, lets think about who will use abbreviations and why they need
them, second, think about where the information could come from.
Situations where expansions of abbreviations are needed:
1) People unfamiliar with the topic being discussed. This can happen
if you click a link to an anchor half-way down a page and miss the
introduction, or you are reading about a topic new to you. It should
not be required that the user screw around looking for the acronym
with a dotted underline. This would be terrible for users of non-
visual UAs or UAs that don't differentiate abbrs from normal text.
2) Documents that exist as both a single page, and as multiple pages
(like large web specifications). Should the expansion occur once per
file? That would require additionally marking up every abbr at it's
first occurrence on a page when splitting the single-page version.
3) Documents that use the same acronym to mean different things in
For example, take that both <abbr title="United States of
America">USA</abbr> and <abbr title="United Space Alliance">USA</abbr>
previously occurred in the document, and you *don't* want, as an
author, for every future use of either term to be expanded by default
(so will not provide titles for all occurrences). I then jump into the
middle of a page from somewhere else and see "The USA's fleet of Space
Shuttles are refurbished by USA, LLC." and wonder what's going on!
There's no way to tell which is which without heuristical analysis of
the language, so the UA can't auto-expand based on a single previous
occurrence, which I think is the behaviour you were expecting by
disallowing abbrs without titles and removing the referencing.
4) Documents where the acronym and an identically spelled word appear.
For example your current system would *require ambiguity* in the
admittedly somewhat unlikely newspaper headline:
<h1><abbr title="British American Racing">BAR</abbr> RAISE THE BAR IN
Is the second BAR an acronym, which is prohibited from being marked
up, or not?No way to tell without heuristical analysis of the
language. Certainly not something most UAs will be doing, even for
English. What hope would Nahuatl have?
At least with <abbr>BAR</abbr> you can tell that it *is* an
abbreviation, and can go look for the reference. Telling when a word
that's not marked up is or isn't an acronym (so deciding if the UA
should provide an expansion) is much harder.
Ideally users need to have on-demand expansion of any abbreviation
they come across, in any situation, regardless of how competent the
HTML author was. Erroneous expansion of non-abbreviations that match a
previously defined abbreviation is I think the hardest thing to avoid.
Where should these expansions come from? The following fallback list
1) Inline with @title, the way it's currently done.
2) By referencing, either automatically by the UA or explicitly marked
up, an expanded occurrence of the acronym.
3) Glossary file in <link> tag, which the UA can apply if unambiguous
or could be referenced by markup. Not currently a feature of any UA.
4) User's application- or system-wide lexicon file, containing terms
in that user's field of occupation. On the Mac OS this is located
under VoiceOver Utility→Speech→Pronunciation.
5) Lexicon of the synthesiser, if one is being used.
You are prohibiting (2) from being used, with the following
a) Documents will either mark up every acronym with an <abbr title=…
> tag—user agents that expand these by default (primarily aural as I
understand it) will appear very verbose—or,
b) Documents will only mark up the first occurrence. UAs that do not
process subsequent occurrences of the abbreviation (currently all of
them), will suffer from lack of definitions.
c) In documents with the same abbreviation occurring for two
different expansions, UAs will have no means of disambiguating without
Using <a> to achieve referencing is a very bad idea, as it will pepper
documents with little blue underlined words and will and up far more
distracting than useful to users. Designers will also hate it, so it
will end up not being used at all.
Lastly, by disallowing the title attribute to be omitted you make
things unnecessarily difficult for currently valid HTML4 to migrate to
— Nicholas Shanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2427 bytes
Desc: not available
More information about the whatwg