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

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

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 26 Nov 2008 22:20:29 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0811262158500.17414@hixie.dreamhostps.com>
On Wed, 23 Apr 2008, Jon Gibbins (dotjay) wrote:
> > > 
> > > 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.
> > 
> > I didn't expect any autoexpading at all. Ever, even with <abbr> 
> > present with a title="" attribute. Why would one want that? That would 
> > be really annoying. We have acronyms and abbreviations for a reason -- 
> > to make things shorter! :-)
> 
> People with learning disabilities, the elderly or people unfamiliar with 
> certain jargon may prefer to have certain, or even all, abbreviations 
> display in their expanded form by default. I know I can never remember 
> what all the US state codes are, for example.

I still wouldn't expect title-free <abbr>s to expand by default, for the 
very reason described above.


> > > 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,
> > 
> > User agents that expand abbreviations by default are poor, IMHO.
> 
> There are certain options to expand abbreviations in place of the 
> abbreviated form in both JAWS and Window-Eyes screen readers, but this 
> is not default behaviour in either case.

That seems reasonable.


> > > 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.
> > 
> > I don't follow this. Why would documents only mark up the first one?
> 
> I think the confusion here is that current best practice is to only mark 
> up the first abbreviation in a page with the expansion to avoid verbose 
> output to users. To all intents and purposes, such advice should be 
> ignored for reasons already identified to the list (i.e. you can't know 
> a user's entry point into a document). However, it *could* be a 
> preference in software to only expand the first occurence thus putting 
> control back into the hands of the user. The problem that remains is how 
> to disambiguate abbreviations that have more than one expanded form.

Authors should use the title="" attribute to include the expansion if they 
want their pages to be clear.


> In my opinion, a more useful solution is to offer some form of 
> infrastructure for glossaries where abbreviations can be uniquely 
> identified to an expanded form. This would aid disambiguation and give 
> control of rendering to users via their user agent.

I don't see why just having the title="" attribute isn't enough.


I've added a note to the spec that says that authors shouldn't expect a UA 
to expand abbreviations just based on earlier <abbr> elements with the 
same contents.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 26 November 2008 14:20:29 UTC

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