- From: Philip Taylor <pjt47@cam.ac.uk>
- Date: Mon, 21 Apr 2008 18:31:03 +0100
- To: "Patrick H. Lauke" <redux@splintered.co.uk>
- CC: public-html@w3.org
Patrick H. Lauke wrote: > > Smylers wrote: > >> What in practice would you expect AT to do with this knowledge? >> Remember that most abbreviations that aren't being tagged with >> expansions won't be marked up, so AT is going to have to deal sensibly >> with that case anyway. > > So you'd prefer hit and miss heuristics over unambiguous interpretation? <abbr> does not allow unambiguous interpretation, since it will be misused and abused, so heuristics are necessary to give a decent user experience even with those elements. (Any other feature will also be misused and abused, so that is unavoidable.) http://philip.html5.org/data/abbr-acronym.txt shows some existing uses of <abbr> and <acronym>: <abbr> is used a lot for dates ('<abbr title="2007-10-05T13:33:09-0400">Friday, October 5, 2007</abbr>'), so it has to be treated as equivalent to non-marked-up text in at least those cases. <acronym> is used a lot for things that aren't acronyms ('<acronym title="Forum Home">MUSICFANTALK</acronym>', '<acronym title="Greg Powell and Mike Donovan are fictional characters [snip lots of text]">Powell and Donovan</acronym>'), where people just want the styling and tooltip effects, so it also has to be treated as equivalent to non-marked-up text in those cases. (Currently HTML5 requires <acronym> to be replaced with <abbr>, so these problems would apply to <abbr> in the future.) The markup elements can be used as additional input information to guide the heuristics, which may (or may not) be much better than without that information, but there will always be some ambiguity that implementations will have to cope with. -- Philip Taylor pjt47@cam.ac.uk
Received on Monday, 21 April 2008 17:31:37 UTC