- From: Nicholas Shanks <contact@nickshanks.com>
- Date: Mon, 21 Apr 2008 15:54:05 +0200
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