A client-side imagemap with server-side map fallthrough can make mozilla display the server-side imagemap if the client-side imagemap lacks a shape=default. This is something of a change in behaviour from Netscape. If there's no ISMAP tag, following the HREF is fine. If there's an ISMAP and we're in quirks mode, it's not what I would expect. (and are login email addresses now lower-case only? I had a devil of a time logging in.)
Uh, why does ismap "suggest that's a bad idea"? I realize the current method isn't backwards-compat with NS4.x, but it doesn't seem out of the bounds of reasonable interpretation, either...
The ISMAP tag indicates that the enclosing HREF link is to the imagemap itself, not to a default link to be followed. Thus, following the link and displaying the imagemap content is a bad idea and (as the ISMAP tag indicates) should be avoided; if the imagemap specifies no default behaviour, do nothing instead when the user clicks on a default region.
So the question is, is this quirk something that would affect enough sites to make it worth the complexity and code needed to implement it? My feeling is "no".
I'm not sure that my mentioning of quirks mode makes it a 'quirk'. The ISMAP tag indicates how (and that) the surrounding HREF content should be parsed. Internet Explorer doesn't have this problem; IE is fundamentally better at image-map handling. Lynx is better at rendering loaded image maps into a list of text links.
The problem is that the entire definition of ISMAP is fundamentally incompatible with the DOM event model. There is a click. This click bubbles. If it bubbles up to the <a>, the <a> will be followed. Unless we want to make the case that an image which has an imagemap should cancel click events even in cases when the click is on an inactive area (bizarre definition of "inactive").
It's how it bubbles. You don't necessarily want to cancel the click, but could interpret the href in light of the ISMAP tag. I'd expect fallthrough from client-side imagemap to server-side imagemap if the point clicked is unspecified in client-side usemap. The maps don't have to be identical; you could have static areas in the client-side map, and dynamic areas elsewhere in the server-side map. Under the current behaviour, that sort of elegance is simply not possible.
Ah, ok. So you just want server-side imagemap support in general. Sure. Can do.
You've got it - the fallthrough of an unspecified default in the client map is simply the most obvious case of this client-to-server-side map fallthrough failing, and it should be supported. We shouldn't be falling through to displaying the server-side map, but should be parsing that as a map instead. (Think of the client map as a layer in front of the server map layer in front of the image, if that helps. Right now, you can have either a single client or server-side layer in front of the image, but you can't layer them together.)
> but should be parsing that as a map instead. Um... That's not what the HTML spec says about how server-side imagemaps work. From http://www.w3.org/TR/html401/struct/objects.html#h-13.6: Server-side. When a user activates a region of a server-side image map with a mouse, the pixel coordinates of the click are sent to the server-side agent specified by the href attribute of the A element. The server-side agent interprets the coordinates and performs some action. So if you have: <a href="foo"><img ismap></a> And I click at the point (10, 20) on the image, Mozilla should just load: "foo?10,20" (resolving it relative to the document base URI, of course). What exactly gave you the idea that the _client_ has anything to do with the processing of _server_ side imagemaps? Is there something I'm missing here? Or is this just a "you should do what IE does" kinda thing?
oops, mea culpa - replace 'parsing' with 'treating'. In the default case I opened this on, the click ?x,y on an unspecified region is not being passed through to the server-side map. I'm arguing that if the clicked coordinates aren't covered by a region in a client-side map (i.e. there is no default region, which otherwise covers everything that is left) and a server-side map is specified (ismap and a href) then those coordinates should be passed through for server-side processing. Clearer?
OK, that's what I thought you meant, till comment 10. ;) Taking bug; this should not be that hard to do...
Hmm.. So I just loaded http://www.ee.surrey.ac.uk/Personal/L.Wood/mozilla/bug-3.html, clicked on a part of the image not covered by an explicit imagemap area, and got taken to http://www.ee.surrey.ac.uk/Personal/L.Wood/mozilla/pocket.map?20,31 This seems correct to me. What is the problem again, exactly?
http://www.ee.surrey.ac.uk/Personal/L.Wood/mozilla/pocket.map?20,31 displayed onscreen in mozilla the imagemap contents themselves (and certainly does that in 1.4b). You should not be able to read the server-side map onscreen. Turns out that this is because Apache has deprecated default use of mod_imap http://httpd.apache.org/docs/mod/mod_imap.html Adding: AddHandler imap-file map to the .htaccess of a parent directory fixed that. Turns out that was confusing me on how client-side/server-side worked; I just added default http://www.mit.edu/ to the server-side map in the example. With AddHandler working right, clicking on a background area unspecified in the client map takes us to the server map, and to the MIT homepage. That's not specified in the client map, so client/server fallthrough is actually working how I imagined it should anyway. Marking this bug as invalid.
Ran into this one again looking at http://www.btimes.co.za/97/0406/tech/tech6.htm and clicking on the imagemapped buttonbar - Apache server, map is served out rather than parsed, again because Apache has deprecated default use of mod_imap http://httpd.apache.org/docs/mod/mod_imap.html This is likely an evangelism/education issue?