W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2008

[whatwg] Feeedback on <dfn>, <abbr>, and other elements related to cross-references

From: Nicholas Shanks <contact@nickshanks.com>
Date: Mon, 21 Apr 2008 15:54:05 +0200
Message-ID: <9C6E4E17-A4F5-4144-BFD6-C25B5165E0A2@nickshanks.com>
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  
different contexts/sections.
	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  
FORMULA ONE<h1>
	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  
seems reasonable:
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  
consequences:
	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  
linguistic processing.


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  
valid HTML5.


? Nicholas Shanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2427 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080421/abd1abef/attachment.bin>
Received on Monday, 21 April 2008 06:54:05 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:02 UTC