Re: Dynamic imagemaps

Dave Raggett wrote:

> This sounds reasonable to me, but it would break downlevel user
agents.

Any more than client-side image maps do now? Anyway, I just discovered
I'm beating a dead horse. Percentage values are already acceptable
according to the description of the MAP element in the 3.2 Reference
Specification:

   If x and y values are given with a percent sign as a suffix, 
   the values should be interpreted as percentages of the
   image's width and height, respectively. For example: 

      SHAPE=RECT COORDS="0, 0, 50%, 100%"

So, there really are new things in 3.2, and good ones at that.

> Another change needed is the ability to specify client-side image
maps
> for image submit buttons (INPUT TYPE=IMAGE). This is needed on
> accessibility grounds, to enable text-only browsers to offer a
textual
> menu of choices.

Sounds right. Add the USEMAP attribute to INPUT. Present the ALTs from
the MAP in the text browser. Set the name.x name.y VALUEs of the INPUT
to the corresponding coords in the MAP. That way the form processor
doesn't have to care what kind of browser the input came from.

There are two other considerations here: image size and percentage
coordinates. With thoughts again to sizeable vector graphics, INPUT
TYPE=image should also accept HEIGHT and WIDTH attributes. And when
USEMAP is present, the coordinate values passed to the form processor
should be in the same units (PX or %) as the MAP.

How many text browsers are there? Why don't the makers form a
consortium and implement this en masse? Building in support for
percentage coords would be trivial in a text browser.

BTW, I think USEMAP would make a dandy TABLE attribute, with
coordinates representing RC pairs. Row 1, Col 1 -> COORDS = "1,1,1,1",
etc. A single set of MAP coordinates could thus reference multiple
cells. For example, COORDS = "1,1,1,3" would reference the first three
cells of the first row. This would allow setting up formatted selection
lists with multi-column data. The standard form fields are sooo ugly,
and so different from UA to UA.

David Perrell

Received on Friday, 7 March 1997 15:41:32 UTC