- From: <S.N.Brodie@ecs.soton.ac.uk>
- Date: Thu, 24 Oct 1996 10:32:28 +0100 (BST)
- To: neko@greenie.muc.de (Simone Demmel)
- Cc: I.End@bigpic.com, www-html@w3.org
Simone Demmel wrote: > > Imagination's End wrote: > > <IMG SRC="testimgp.jpg" WIDTH=590 HEIGHT=387 USEMAP="#MAP"> > > <MAP NAME="MAP"> > > <area shape=rect coords="100,100,400,400" alt="Area 1" href="area1.html"> > > <area shape=rect coords="200,200,300,300" alt="Area2" href="area2.html"> > > </MAP> > > STandard behaviour is to have Area #1 obscruing Area #2, but is that > > supposed to be what happens? It doesn't it seem intuitive that as > > areas are created they are put further behind in the Z-Order. > > It seems to be that the browser interpretes the first matching field, he > can find. That means: > > 100,100,200,200 > 120,120,190,190 > will never see the area in 120,120,190,190. > > This beahvior is only a TEST!!! Netscape is doing it like this, and I > have also seen this beahvior on Server-Sided immagemaps. The Seidman draft which turned into an informational RFC (RFC1980) declared that this was the behaviour required. (See 2nd paragraph of page 4) > (I think it is easier to implement like this) Frankly, it doesn't matter. As far as I'm concerned, when I parse a map, I construct a linked list of areas and add each new one to the tail of the list. When a CSIM is clicked or the mouse is over it, the map is searched by walking along the list until I find an area matching the coordinates. To make the behaviour go the other way, you just add the new areas at the head of the list instead. I suspect that the vast majority of other implementations would work in a similar way. -- Stewart Brodie, Electronics & Computer Science, Southampton University. http://www.ecs.soton.ac.uk/~snb94r/ http://delenn.ecs.soton.ac.uk/
Received on Thursday, 24 October 1996 05:34:08 UTC