Re: Z-Order In Image Maps
Thu, 24 Oct 1996 10:32:28 +0100 (BST)

Message-Id: <>
Subject: Re: Z-Order In Image Maps
To: (Simone Demmel)
Date: Thu, 24 Oct 1996 10:32:28 +0100 (BST)
In-Reply-To: <> from "Simone Demmel" at Oct 24, 96 11:16:39 am

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.