74073 - Should display tooltips for previously defined abbreviations

Status: RESOLVED WONTFIX

(Core :: Layout, enhancement)

Description

[Karl Ove Hufthammer]

Authors can specify expanded abbreviations by using the 'title' attribute:

<p>Welcome to the <abbr title="World Wide Web">WWW</abbr>.</p>

This is recommended by the W3C in their accessibility guidelines
<URL:http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#gl-abbreviated-and-foreign>

Mozilla display abbrs with dotted underlining and the expansion as a tooltip
when hovering over the abbr. (This is a great feature, BTW.) But the guidelines
on tell us to:

"Specify the expansion of each abbreviation or acronym in a document *where it
first occurs*." [My emphasis]

So if I wrote a new paragraph following the one mentioned above:

<p>The <abbr>WWW</abbr> is a very nice place.</p>

'WWW' should be displayed with a a dotted underline and a tooltip (with the same
text as the previous abbreviation). It isn't.

Comment 1

[Hixie (not reading bugmail)]

You misunderstand. The guideline is directed at web authors, not web browser
authors. The guidelines are saying that the web authors should use the <abbr>
or <acronym> element (only) the first time the relevant acronym appears. It
is not saying that the web browser should magically look up the tooltip from
previous occurances of <abbr> or <acronym>.

Marking INVALID.

Comment 2

[Karl Ove Hufthammer]

> You misunderstand. The guideline is directed at web authors,
> not web browser authors.

Yes. But web browsers must (of course) support the markup the web authors use.

>The guidelines are saying that the web authors should
>use the <abbr> or <acronym> element (only) the first
>time the relevant acronym appears.

The guidelines say you should use 'abbr' og 'acronym' *each* time an 
abbreviation or acronym accurs, but only specifiy an *expansion* the first time.

This bug is not invalid. See the W3C User Agent Techniques 
<URL:http://www.w3.org/TR/UAAG10-TECHS/>:

Make available information about abbreviation and acronym expansions. For 
instance, in HTML, look for abbreviations specified by the ABBR and ACRONYM 
elements. The expansion may be given with the "title" attribute (refer to the 
Web Content Accessibility Guidelines 1.0 [WCAG10], checkpoint 4.2). To provide 
expansion information, user agents may: 

* Allow the user to configure that the expansions be used in place of the 
abbreviations, 
* Provide a list of all abbreviations in the document, with their expansions (a 
generated glossary of sorts) 
* Generate a link from an abbreviation to its expansion. 
* Allow the user to query the expansion of a selected or input abbreviation. 
* If an acronym has no explicit expansion in one location, ***look for another 
occurrence in content with an explicit expansion. User agents may also look for 
possible expansions (e.g., in parentheses) in surrounding context, though that 
is a less reliable repair.***

Reopening.

Comment 3

[Hixie (not reading bugmail)]

Fair enough. But this is not a bug 7954 blocker, since the HTML spec doesn't
say anything about that kind of behaviour (in fact, someone should probably
tell the HTML working group that their markup language's semantics are being
redefined by the WAI groups).

This will require some hard coded, special cased logic in the relevant HTML
element frames.

Comment 4

[Karl Ove Hufthammer]

> Fair enough. But this is not a bug 7954 blocker, since the
> HTML spec doesn't say anything about that kind of behaviour

The HTML spec says very little on the rendering/behaviour of most elements (on 
purpose, actually).

> (in fact, someone should probably
> tell the HTML working group that their markup
> language's semantics are being
> redefined by the WAI groups).

?

How are they changing the semantics of the 'abbr' (and 'acronym') element(s)? 
The semantics of the 'abbr' element is:

"Indicates an abbreviated form (e.g., WWW, HTTP, URI, Mass., etc.)."

The UAG only recommends ways this can be presented to the user.

Comment 5

[Robin Lionheart]

Sometimes this would be an undesirable feature.

For example, say a page about the IRS uses the "IRS" abbreviation every couple of sentences. It is properly marked up with <abbr>IRS</abbr> throughout so that speechreaders don't say "urse". The first occurrence also uses <abbr title="Internal Revenue Service">IRS</abbr>.

If every single occurence of IRS were visually marked, the page would become filled with distracting dotted underlines, making it less readable. 

It might be a useful feature for the subsequent uses of the abbreviation to have the title pop-ups but not the dotted underlines, though.

Comment 6

[Karl Ove Hufthammer]

> It might be a useful feature for the subsequent uses
> of the abbreviation to have the title pop-ups but not
> the dotted underlines, though.

I agree. It isn't necessary to display the dotted underline for subsequent
'abbr's, only the title. (It's easier this way too, since the underline is just
a CSS rule in 'ua.css'.)

Comment 7

[Hixie (not reading bugmail)]

Karl: The reason this bug is not a 7954 blocker is that this bug doesn't 
relate to anything given in the HTML spec. All the HTML spec says is that 
"title" might be used for a tooltip (done) and "<abbr>" and "<acronym>" are
used to show where abbreviations appear (also done).

Extra support like what the WAI group recommends or RFEs that would make our 
HTML support even better (e.g., "make <dfn> elements link to dictionary.com")
are not bugs that block our full support of HTML.

Comment 8

[Matthew T (active 1999-2002)]

I don't think this should be implemented.

Using ABBR/ACRONYM without a TITLE is analagous to using a pronoun rather than 
a proper noun -- you don't need to give the full expansion, because (if the 
user has read the preceding part of the document, and it's reasonable to assume 
that they have) the user already knows what the full expansion is. If I recited 
the name Karl Ove Hufthammer whenever referring to a bug which Karl Ove 
Hufthammer had filed or which Karl Ove Hufthammer had added Karl Ove 
Hufthammer's name to the CC list of, rather than just using `he'/`his'/`him', 
that would get pretty annoying. Similarly, showing the tooltip for every ABBR 
or ACRONYM would be pretty annoying, as Robin said.

Maybe it was late at night when the W3C UAAG working group came up with this 
technique, and they were short on caffeine. Who knows.

Comment 9

[Karl Ove Hufthammer]

> Using ABBR/ACRONYM without a TITLE is analagous to using
> a pronoun rather than 
> a proper noun

That's a terrible analogy.

> user has read the preceding part of the document,
> and it's reasonable to assume 
> that they have)

No, it's not reasonable to assume that. We're talking about Web pages, not 
ordinary paper documents which are read from beginning to end (as a matter of 
fact, many paper documents are *not* read from beginning to end either, and 
sometimes included a glossary at the end with a list of abbreviations).

> If I recited 
> the name Karl Ove Hufthammer whenever referring to a bug
> which Karl Ove 
> Hufthammer had filed or which Karl Ove Hufthammer
> had added Karl Ove 
> Hufthammer's name to the CC list of, rather than just
> using `he'/`his'/`him', 
> that would get pretty annoying.

Yes, but that's pretty irrelevant here. We're talking about abbreviations. 
Abbreviations have an element specially made for them in HTML. And *we're* not 
talking about displaying an expansion all the time (similarly to saying 'Karl 
Ove Hufthammer' instead of him all the time), we're talking about displaying a 
tooltip whenever the user actively moves the mouse pointer over an abbreviation 
to see what it means.

> Similarly, showing the tooltip for every ABBR 
> or ACRONYM would be pretty annoying, as Robin said.

Why? And how? How often do you "accidently" hover over abbreviations and wait 
~.5 seconds?

> Maybe it was late at night when the W3C UAAG working group
> came up with this technique, and they were short on
> caffeine. Who knows.

They have a public mailing list. You can check its archive if you're interested.

Comment 10

[Matthew T (active 1999-2002)]

> as a matter of fact, many paper documents are *not* read from beginning to
> end either, and sometimes included a glossary at the end with a list of
> abbreviations

Exactly. Paper documents define an abbreviation once, in a glossary, just as 
Web pages define it once using TITLE on its first occurrence. Paper documents 
don't include the expansion of an abbreviation (or pronoun) as a footnote after 
every occurrence, because that would be annoying. It's assumed that if you came 
into the document halfway through, and you don't know what a particular 
abbreviation or pronoun is referring to, that it is *your* job to back up until 
you find the original reference. The same thing applies to Web pages.

> How often do you "accidently" hover over abbreviations and wait ~.5 seconds?

If every abbreviation I read on the Web was marked up with ABBR, I guess I 
would hover accidentally over an abbreviation about once in every 10 or 20 
pages.

> They have a public mailing list. You can check its archive if you're
> interested.

No, I'd much rather judge the idea on its merits. And frankly, this idea does 
not excite me in the slightest.

Comment 11

[Karl Ove Hufthammer]

> Exactly. Paper documents define an abbreviation once,
> in a glossary, just as 
> Web pages define it once using TITLE on its first occurrence.

Yes, and Web pages have the added benefit of having the expansion available 
*without* having to read through the entire document.

>> How often do you "accidently" hover over abbreviations and wait ~.5 seconds?
>
> If every abbreviation I read on the Web was marked up
> with ABBR, I guess I 
> would hover accidentally over an abbreviation about
> once in every 10 or 20 
> pages.

Even if this is true, it isn't very often. And you don't need to just *hover* 
over it, you'll have to wait ~.5 seconds too. I guess you probably hover over 
toolbar buttons *a lot* more often, and don't find this annoying -- and most 
toolbar buttons have tooltips, at least in Windows (and Mozilla).

> No, I'd much rather judge the idea on its merits.
> And frankly, this idea does 
> not excite me in the slightest.

It's not supposed to be "exciting". But I do feel it's important for usability 
(and accessibility).

Comment 12

[Heikki Toivonen (remove -bugzilla when emailing directly)]

HTML Element component is deprecated, and should be removed from Bugzilla.
Clayton is not the correct owner for these. Reassigning to layout.

Comment 13

[Michael Nahrath]

I think this bug should be marked invalid.

Implementing Karl's ideas would annoy users and authors so that it would prevent
them from using the 'abbr' and 'aconyme' element in a propper way (don't you
know these idiot-discussions "I don't use the 'alt' attribute for images because
it produces ugly tooltips in NN4"?)
If an author thinks that this is a wanted feature for his website he is free to
implement it to his site by his own coding.

And Mozilla is strong enough to implement a lot of enhancements by author styles.

eg I was not fully satisfied with the solution for bug 56702. 
So I added "[title] {cursor: help;}" to my homepage's stylesheet. 
No need to bother Mozilla developement with this any further.

Karl, if you want your pages to render 'abbr' and 'acronyme' as you requested,
it is your job to write them in that way. But please leave my pages in peace
with what I would see as tooltip spamming! 

Comment 14

[anthonyd]

not table specific reassigning to core owner.

Comment 15

[Boris Zbarsky [:bzbarsky]]

I also think this should not be implemented... it would be a lot of work for a
very very dubious benefit (and even whether it's a benefit is arguable).

Note that the text cited in comment 2 talks about looking for other
<acronym>/<abbr> elements that have the expansion as _repair_ (as in, repairing
damanged content).

Marking wontfix.