- From: Smylers <Smylers@stripey.com>
- Date: Wed, 23 Apr 2008 23:37:17 +0100
- To: whatwg@lists.whatwg.org, whatwg List <whatwg@whatwg.org>, public-html@w3.org
Nicholas Shanks writes: > 2008/4/23 Ian Hickson <ian@hixie.ch>: > > > Summary: I've made the title="" attribute on <abbr> optional again. > > Maybe we need a smart validator that maintains a set of abbreviations > it comes across, if an <abbr> with no title attribute is encountered > that isn't in the set of already seen abbreviations, a message is > displayed to the web developer saying the new abbreviation should have > a title. Possibly that would useful for web authors. But it wouldn't be any sort of 'validator', since the reason that expansion-less abbreviations are permitted in HTML 5 is so that abbreviations may be styled in a particular way (for example with small caps). That is therefore a valid thing to do whether or not the abbreviation happens to be expanded anywhere else in the document. > > On Mon, 21 Apr 2008, Smylers wrote: > > > > > Why should HTML 5 bother to solve the very narrow case of > > > disambiguating words from abbreviations, but not solve it more > > > generally to include the other cases? > > > > Indeed. > > This is a good point. Smylers, do you think we should remove abbr > altogether and leave solutions to ambiguity problems to something > other than HTML? No; <abbr> with an expansion is useful, particularly for abbreviations coined by the author which readers may not be in a position to otherwise know, or to look up elsewhere. And there are user-agents which make the expansion available. > > On Mon, 21 Apr 2008, Nicholas Shanks wrote: > > > > > > We need to go through this more methodically before making a decision. I > > > hope the following aids matters. > > > > More methodically than > > > > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014470.html > > > > ...? I'm not sure exactly what you have in mind! :-) > > What I meant was you were just addressing people's points as they came > up. That is very methodical; it ensures that every point brought up gets considered. > If we want to do this properly we need to ensure we have covered every > aspect from the beginning. You want Ian to consider points that haven't been raised? Surely the best way of doing that is simply to raise those points? > Set up a focus group or something :) What could a focus group say that people can't do here? > > > Situations where expansions of abbreviations are needed: It should > > > not be required that the user screw around looking for the acronym > > > with a dotted underline. > > > > Abbreviations are no more special here than any term of art. > > except that HTML in is past incarnations provided a solution. The > difference has already been created. It has? Please could you give an example of an existing webpage which successfully uses an <abbr> element without a title and which an existing user-agent does something useful with that. > > It's quite obvious that the "BAR" in "RAISE THE BAR" is not an > > acronym. > > Only if you know English. ('you' being the User Agent who has to > decide how to expand/pronounce it). It is not reasonable to expect > UAs, other than perhaps TTS engines, to correctly identify this. Why would a user-agent that isn't speaking need to correctly identify it? > And to the person who suggested it be written in lowercase, I > explicitly said it was a newspaper headline. That was me. Sorry, I interpreted that to mean a headline on a newspaper's website; I hadn't realized you meant transcribing from a printed newspaper. > You should not change the case of printed material when transferring > it to electronic form, reproductions should be faithful to the > original, and use uppercase characters rather than style > transformations (since they might not get applied). On that basis one could argue for not transcribing it at all, but instead including it as a giant image, to avoid any other changes. Or that headings shouldn't be marked up with <h1> and so on but simply with by setting the appropriate font, since otherwise a browser may not style the <h1>s appropriately. (Conversely, one could argue that what's important is to transcribe the semantics, and where that includes 'headlines are normal sentences but the house style is to display them in all-caps' then it's reasonable to mark them up as I suggested.) If the aim is simply to reproduce the printed page exactly then the original doesn't have any out-of-band indication as to whether "BAR" is a word or an abbreviation (or indeed both, as a pun); why should the web representation? Smylers
Received on Wednesday, 23 April 2008 22:37:10 UTC