Client-side image maps should be scalable

[urbanjost]

An enhancement I would like in HTML5 is that the coordinates in a
client-side image map (see <IMG> , <MAP> , <AREA> in the HTML
documentation) would scale with the image; to be backward-compatible
there would have to be a flag to say the coordinates are relative to
the pixmap and not the displayed size. To demonstrate the problem
I made

http://home.comcast.net/~urbanjost/semaphore.html

This example shows that if the IMG image is resized to 300x300 (click
the button) that the associated coordinates for the AREA areas are
not. At 1000x1000 you can see that the text at the lower left corner
of the image properly changes according to which area you are over. If
you resize the image to 300x300 the messages are wrong because only
the image, not the area coordinates, have been rescaled.

If the option

COORDSCALE="ABSOLUTE|RELATIVE"

or

COORDSCALE="TOPIXEL|TODISPLAYED"

was added to the MAP element, with "TODISPLAYED" being the default,
you could support the new scalability without breaking current maps.

What purpose would this serve? I often want to make an image size
adjustable by the viewer to improve accessibility (large images are
easier to see, smaller images accommodate limited mobility). It is
also useful to be able to adjust image sizes to fit different browser
window sizes, such as the smaller displays often found on portable
devices.

It is possible to maintain multiple maps and to change the USEMAP=
value using JavaScript for a limited set of sizes; but that is a large
amount of work.

In a related vein,
* If it was required that a browser that does not display images (or
one that can but has images suppressed) use the MAP/AREA
information to make a list of the same information either as a
menu or a simple UL-type list that would make it simpler for
developers who often have to duplicate the links in an image map
somewhere else to support non-graphic browsers. lynx(1) and w3m(1)
already do an excellent job of that, using the alt="" values
supplied in the AREA definitions; but that is not something you
are sure you can depend on because it is not in the HTML
specification. If developers knew it would be supported they could
eliminate the duplicate menus you often see on pages with image
maps.
* it is not clear to me whether a CANVAS element will or will not
support a MAP? It would be useful if it did; and it would then be
even more important that CANVAS support an even-odd fill for
polygons to match the fill style used by AREA.

As of Feb 23, 2008 if I remove the name="letters" from the MAP element
this page will not work in safari(1); but it works in opera(1),
iexplore(1), and firefox(1). The HTML5 validator says name="" is not
yet part of HTML5.

References

1. LYNXIMGMAP:file://localhost/home/urbanjs/DISKA/public_html/public/semaphore.html#letters

[zcorpan]

References

1. LYNXIMGMAP:file://localhost/home/urbanjs/DISKA/public_html/public/semaphore.html#letters

Was this intended to be a file: URL?

[urbanjost]

That last line that says 1) Reference:... is an accidental artifact of how I
made the message. I created the message as HTML and then converted
it to text with "lynx -dump FILENAME"; and missed one of the lines
that I wanted to delete from the resulting text field. If it can be deleted it
should be; else ignore it.

The example I referred to is up above in the body of the text.

[urbanjost]

1) When I last looked the HTML4 standard never clarified whether percent
units in an integer list for the COORDS= values in an <AREA> where
relative to the size of the pixmap file, or relative to the displayed size
(ie. relative to the WIDTH= and HEIGHT= values of the <IMG> using the <MAP>).

I had really hoped the percent units where relative to the displayed size, which would make it so one set of COORDS= could be used for different sizes of the same image; making imagemap maintenance much
easier when using resized images.

Empirically, I found this not to be the case' at least with opera, firefox,
chrome, iexplorer, .... and whatever else I tried at the time.

2) Remembering this, I looked at the HTML5 spec. to see how it described the use of percent units for coordinates.
A) I found it said coordinates could only be a list of integers as described in 2.4.3.6. Does this mean percent coordinates are not allowed
in HTMl5?
B) As I read 2.4.3.6 it states in the first paragraph that the only allowed
delimiter is a comma; and specifically states spaces are not allowed.

But in rule 6 of 2.4.3.6 it seems to imply a space, comma, or semi-colon is an allowed delimiter in a "List of Integers".

So .. did I miss something or are percent-units no longer allowed as coordinates? What are the delimiters allowed in a list of integers? And, I
wish percent units scaled to the displayed image size ( as I mentioned in
http://home.comcast.net/~urbanjost/semaphore.html ). If percent units are permitted, I think it would be worth mentioning what they are a percent
of (image file units or displayed image size units).