8131 - Behaviour of image maps with broken images (i.e. AREA and alt text)

Status: NEW

(Core :: Layout: Images, Video, and HTML Frames, enhancement, P2)

Description

[petitta]

(This bug imported from BugSplat, Netscape's internal bugsystem.  It
was known there as bug #122145
http://scopus.netscape.com/bugsplat/show_bug.cgi?id=122145
Imported into Bugzilla on 06/14/99 15:38)

Some shapes do not reflect alternative text - specifically circles and
sometimes, the polygon shapes.

1. Go to: http://slip/projects/marvin/bugs/imagemap/imagemap_bug.html.
2. Mouse over each of the shapes to see the alternative text.

Cannot get the alternative text to show when I mouse over circles. For the
yellow polygons, I can get the alternative text if I mouse over the top point,
but it is inconsistent. Also inconsistent are the two large brown polygons.
Alternative text for the blue squares is no problem.

Comment 1

[rubydoo123]

setting TFV to 5.0 per dp
setting owner to Pam per dp
setting Christine to QA Assigned to per me

Comment 2

[Christine Hoffman]

*** Bug 122141 has been marked as a duplicate of this bug. ***

Comment 3

[Christine Hoffman]

*** Bug 322992 has been marked as a duplicate of this bug. ***

Comment 4

[Christine Hoffman]

Additional comments from duplicate bug #322992:

Win 95 has this problem as well. In UNIX, there is no alternative text using the
URL: http://slip/projects/marvin/bugs/imagemap/imagemap_bug.html

Comment 5

[Christine Hoffman]

Revised initial comments to simplify explanation. As state, you can use:

'http://slip/projects/marvin/bugs/imagemap/imagemap_bug.html' as the bug example



------- Additional Comments From elig  Jun-04-1999 11:44 -------

[QA Assigning to self for verification in 5.0, upon fixing of 1358.

Moving to Bugzilla because I'll never remember to check it again if it's left in
Bugsplat.]

Comment 6

[pnunn]

kipp:
Who handles image maps? I see your name in the cvs log
on nsImageMap.cpp so I thought I'd start with you.
-p

Comment 7

[kipp]

Umm, I tried it in apprunner and it works great. I also tried it in viewer and
it works great...where's the bug?

Comment 8

[petitta]

I wrote this up over a year ago, when gromit was still in our vocabulary. Forgot

the bug even existed, shame on me!!!  Anyway, Eli if you would be so kind as to

take a look at this and close upon confirmation, I would be greatful....

Comment 9

[Eli Goldberg]

Sure; the bug is my "Jun-04-1999" comment --- namely, that I was importing it as
a reminder to myself to confirm that it was definitively fixed.

Probably should have marked it as RESOLVED/FIXED from the start. ;) Will verify
this within 2 business days.

Comment 10

[Eli Goldberg]

After reading through 13.6 of the HTML 4 spec, I'm really not sure how to
proceed:

	* The behavior that the bug report specifies --- that ALT tags should appear
upon mousing over images --- is not specified (as far as I can tell) within the
HTML 4 spec, and thus, is not supported by Seamonkey, as far as I'm aware.

The following test cases, I think, would cover the specification:

	* Configure the user agent to not display images, in which case the ALT text
strings should appear in the image map in lieu of the image.

	However, there's no way to do this, so I can't. ;)

	* Delete the image referenced by the image map. ("User agents and authors
shouuld offer textual alternates to graphical image maps for cases when graphics
are not available or the user cannot access them." p. 165)

	However, if I do this, the ALT text doesn't appear as I expect it to --- it
just displays the image file name.

---

	There's only one thing a respectable tester can do. Unveiling the magic lamp
stowed away in the xHead pit, I doth summon the venerable ALT Text genie himself,
Ian Hickson.

	So, Ian, I'm not sure how many wishes are left, but if you have any words of
wisdom, they'd be most appreciated. ;) Thank you!

Comment 11

[Eli Goldberg]

[and, yes, I'll attach the test case ASAP.]

Comment 12

[Eli Goldberg]

Attachment: Test Case (1 of 2)

Comment 13

[Eli Goldberg]

Attachment: Test Case (2 of 2)

Comment 14

[Hixie (not reading bugmail)]

elig: The magic lamp has been upgraded, nowadays sumoning it results in the QA
contact being replaced. :-O

We shouldn't be using 'alt' for the tooltips, we should be using 'title' for
the tooltips. But the alt text (possibly the <AREA>s') should indeed be used
when the image of a client side image map is not available. NOTE: This is
likely to be not very easy to implement, I expect at some point in the near
future we will see troy marking this REMIND...

[updating summary as per bug description]

Comment 15

[Hixie (not reading bugmail)]

Ok. Our current behaviour is unacceptable, since it results in the links being
unusable. (IE5's behaviour is equally bad: the links are usable, but absolutely
no feedback is given as to where the links are, or what they represent, since
no alternative to image is provided if the image is not shown.)

What we should be doing is making a 'menu' from the <area> elements, if the map
contains any <area> elements, or displaying inert text otherwise. I will draw
up a more detailed behaviour spec in the next few minutes. I have also
requested a spec clarification from the authors of HTML4.01 since it is not
clear what should happen when the MAP contains AREA elements _and_ normal A
elements with coordinates.

Some other image map bugs: bug 1427, bug 7304, bug 10545, bug 12721, bug 9140,
bug 1882, bug 8027.

I am setting up some dependencies and expanding the scope of the bug summary.

Comment 16

[Hixie (not reading bugmail)]

Here is a first draft of the possible behaviours that we should be exhibiting
when trying to render an IMG element marked USEMAP for which we cannot actually
render the image (e.g. because images are disabled).

=======================================================================

1a. If the MAP element contains AREA elements, then:

   Option 1: If dynamic transforms are not beyond the layout team:

      1. Act as if the AREA elements found in the IMG's linked MAP were [also]
         children of the IMG element, and apply the following styles:

            IMG { display: block; } /* or inline-block */
            IMG AREA { display: list-item; }
            IMG AREA:after { content: attr(alt); }

      2. Make sure AREA elements are recognised as links (just like A,
         LINK, and XLinks).


   Option 2: If dynamic context menus are not beyond the UI team:

      1. Replace the IMG by its alt text, and style it as if it was a
         link (this already happens, except for the underlining).

      2. When someone clicks on the IMG alt text, generate a menu from
         the 'alt' texts of all the AREA elements of that IMG's MAP.
         Display the menu.

      3. When someone selects one of the menu items, go to the URI
         selected by the relevant AREA's href attribute.


   Option 3: If intelligent behaviour must wait until the 5.1 release:

      1. DO NOT replace the IMG with it's alt text. Display, instead,
         the placeholder box with the broken object glyph and the alt
         text inside the box.

      2. Act as if that was the real IMG, thus giving the placeholder
         box the hotspots that the <MAP> element specifies.

     Note that this option causes accessibility problems and is
     non-spec compliant.


1b. Else: If the MAP element does not contain any AREA elements, then:

   1. Act as if the IMG element was not marked USEMAP.
      (i.e., display the alt text, but do not style it blue with a
      hand cursor.) This probably requires that bug 11011 be fixed.

=======================================================================

Ok, which of the options for (1) are we going to implement?

Comment 17

[kipp]

Here's one for you to look at; I'd just later it, but we probably need to do
something better for failed image maps.

Comment 18

[Hixie (not reading bugmail)]

Note. I'm currently in talks with the HTML4.01 editors to find out what we
should do. The discussion is being cc'ed to the www-html forum if you wish
to read it. The thread in the archives starts at:
   http://lists.w3.org/Archives/Public/www-html/1999Oct/0113.html
I suggest not doing anything until this is sorted out.

Comment 19

[Nisheeth Ranjan]

Accepting bug...

Comment 20

[Hixie (not reading bugmail)]

Ok, talk with the html4 spec people has concluded with this behaviour spec:
   http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/usemap-alt.txt

Is there any way for the layout engine to style elements in ways that the CSS
selector syntax cannot do? According to the behaviour spec, we need to apply
different styles to AREA elements if the IMG element is broken and the MAP
element only contains AREA elements. Is this possible?

Comment 21

[Nisheeth Ranjan]

I'm not sure whether this is possible or not.  Ccing Troy and Pierre.  Please
take a look at Ian's comment (11/18/99 10:47) on this bug report and answer it.
Thanks.

Comment 22

[Pierre Saslawsky]

It's not possible to do that within the Style System but maybe in Layout, so I'll
let Troy answer.

Comment 23

[troy]

As usual Ian did a fine job of describing the landscape. At this point given how
we needed to be done last week option #3 seems the most sensible to. It should
be a simple matter of changing the image frame code so that if it is an image
map that can't be loaded we just display the broken icon and don't try to
display the alternate content

Comment 24

[Hixie (not reading bugmail)]

Agreed. Whoever implements this temporary fix should resolve this bug as LATER
and we can look at it again for 5.1.

Comment 25

[Hixie (not reading bugmail)]

*** Bug 28822 has been marked as a duplicate of this bug. ***

Comment 26

[Nisheeth Ranjan]

I have the temporary fix in my tree...  Will check in once the tree is open and 
green.

Comment 27

[Nisheeth Ranjan]

The fix is checked in.

Comment 28

[Nisheeth Ranjan]

Actually, I wanted to later this one.   Re-opening and latering.

Comment 29

[Nisheeth Ranjan]

Latering...

Comment 30

[Hixie (not reading bugmail)]

VERIFIED that our current behaviour is 4xP but suboptimal and that we will
revisit this after FCS. A specification of better behaviour is at 
   http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/usemap-alt.txt

Comment 31

[Hixie (not reading bugmail)]

Reopening and moving to Future...

Comment 32

[Hixie (not reading bugmail)]

...so that it appears on my radar.

Comment 33

[Hixie (not reading bugmail)]

erm, _really_ reopening...

Comment 34

[Ed Avis]

If I understand you correctly, Mozilla will deliberately _not_ show ALT text as
a tooltip, not for imagemaps, not for ordinary images, not anywhere else.  The
only use of ALT text is when the image itself is not displayed.  Can you confirm
that this is your official policy?

Although tooltippifying ALT text may not be part of the W3C's recommendations,
wouldn't it be worth keeping for compatibility with existing browsers?  I don't
think any web page author is going to complain that you're displaying the extra
information to the user, and I don't think users are going to complain either. 
It looks to me like a useful addition to the browser, especially since many more
pages have ALT than have TITLE.

Comment 35

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It's bad to show ALT text in tooltips because that encourages page authors to
put text in ALT attributes because they want it to appear in a tooltip.  Such
text generally makes very bad alternate text for people who don't/can't load
images.  Encoraging authors to create such text hurts accessibility of the web.

Comment 36

[rubydoo123]

removing myself from the cc list

Comment 37

[Stuart Parmenter]

changing component to layout

Comment 38

[Christopher Hoess (gone)]

->Image: Layout

Comment 39

[Stanimir Stamenkov]

Attachment: Another Test Case

Just another test case.

Suppose that "images/links1.png" has 300x50 pixels dimensions and
"images/links2.png" has 200x50 pixels dimensions.

Comment 40

[Dennis Simonsen]

(In reply to comment #35)
> It's bad to show ALT text in tooltips because that encourages page authors to
> put text in ALT attributes because they want it to appear in a tooltip.  Such
> text generally makes very bad alternate text for people who don't/can't load
> images.  Encoraging authors to create such text hurts accessibility of the web.

I don't agree with your opinion, since using "alt" is sometimes a great
enhancement for authors ie to clarify what the image map is. Look at
http://arbetarteater.nu > click on "Våra Teatrar" and you find a map over sweden
with small red dots, those dots are clickable links and contains a alt text that
explains what city the dot leads to. This is just one example of how to use the
alt attribute. It works in IE6.0
Regards
Dennis

Comment 41

[Stanimir Stamenkov]

(In reply to comment #40)
> I don't agree with your opinion, since using "alt" is sometimes a great
> enhancement for authors ie to clarify what the image map is. Look at
> http://arbetarteater.nu > click on "Våra Teatrar" and you find a map over
> sweden11
> with small red dots, those dots are clickable links and contains a alt text
> that
> explains what city the dot leads to. This is just one example of how to use
> the
> alt attribute. It works in IE6.0

Man, you're falling from Mars. Just read:

"Guidelines on alt texts in img elements"
<http://www.cs.tut.fi/~jkorpela/html/alt.html>

more precisely:

http://www.cs.tut.fi/~jkorpela/html/alt.html#tooltip

You could also read the spec:

http://www.w3.org/TR/html4/struct/global.html#title

Comment 42

[Gérard Talbot]

*** Bug 321621 has been marked as a duplicate of this bug. ***

Comment 43

[Jesse Ruderman]

*** Bug 332458 has been marked as a duplicate of this bug. ***

Comment 44

[Jez]

Heh, I see this bug still hasn't been fixed with Gecko.

Wow, filed in the Netscape 5 days.

Broken imagemap images still just display the broken image glyph.  I'm quite surprised this one hasn't been fixed actually.  It seems quite trivial to replace the imagemap image with a bulletpoint list of AREA links, using the IMG's ALT text as a title if specified.

Comment 46

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This might be possible now with the broken-image psuedoclasses.

Comment 47

[Boris Zbarsky [:bzbarsky]]

Possibly, yes.  At the moment, we never replace an imagemapped image with alt text, because doing that would make the imagemap not work.  We could create alt content that contains <a> nodes, I guess; the hard part is getting it to respond to mutations on the <map>.

Comment 48

[Leif Halvard Silli]

Since Firefox 4, this has detorated, see this test case from bug 592538 (it is a object element image map):

https://bug592538.bugzilla.mozilla.org/attachment.cgi?id=595945

In Firefox 3.6, the <area> element are visible, via styling that bears some similarity to that which Hixie suggested in Comment 16. But now, since Firefox 4, the <area> element is impossible to style: Its computed style is {display:none}, whatever one does.

Comment 49

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates and 14 votes.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 50

[Emilio Cobos Álvarez (:emilio)]

imagemaps these days are probably not a priority to be more than an s3.