(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.

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

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

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

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

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.]

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

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

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....

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.

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!

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

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]

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.

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?

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.

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.

Accepting bug...

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?

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.

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

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

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

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

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

The fix is checked in.

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

Latering...

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

Reopening and moving to Future...

...so that it appears on my radar.

erm, _really_ reopening...

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.

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.

removing myself from the cc list

changing component to layout

->Image: Layout

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

(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

(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

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

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

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.

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

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>.

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.