HTML image maps should rescale

A major limitation of HTML image maps that makes them difficult to maintain and use, is that the image map data has to be made for each image size. This limitation could easily be removed by either defining percent units for coordinates as being relative to the displayed image size, or by adding a new parameter, as discussed below.

NATO phonic alphabet ALPHA BRAVO CHARLIE DELTA ECHO FOXTROT GOLF HOTEL INDIA JULIET KILO LIMA MIKE NOVEMBER OSCAR PAPA QUEBEC ROMEO SIERRA TANGO UNIFORM VICTOR WHISKEY XRAY YANKEE ZULU ONE TWO THREE FOUR FIVE SIX SEVEN EIGHT NINE ZERO

This is an example image map used to discuss an enhancement request for HTML. This is a large single image where each flag can be clicked on to go to a new region. In this example, they all go to the same page. Assuming you are in a graphical browser that supports JavaScript, you can see that as you enter each flag region, a description of the flag appears just below the image.

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.

If the option
COORDSCALE="ABSOLUTE|RELATIVE"
or
COORDSCALE="TOPIXEL|TODISPLAYED"
or
referenceGeometry="500,500"
was added to the MAP element, with mapping to the displayed size instead of the image size being the default, you could support the new scalability without breaking current maps.

What purpose would this serve? It is useful to be able to adjust image sizes to fit different browser window sizes, such as the smaller displays often found on portable devices. Having the image map rescale with the image would be useful for limited zooming on geographic map images, for example. I often want to make an image size adjustable by the viewer, either to maintain page layout relative to the browser's display size, or to maximize ease of use of the image map (large images are easier to see, smaller images accommodate limited mobility, for example). The maps are generally difficult to generate (especially by hand); having to create a new one for an image just because you want a different size for it means a lot of effort that can be eliminated very easily.

There are also no reasons to make the image map not scale. If the image changes size, the map data becomes useless. It would be better to make images used as image maps unscalable rather than let such errors occur.

But this capability seems easy to add, and there are as many reasons to want it as there are reasons to resize a window in a GUI environment. The use of percent units in coordinates seems to be the easiest way to implement this without breaking existing documents.

In a related vein, 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 (which it currently does not).

John S. Urban, Feb 23, 2008
VALIDATE HTML5 VALIDATE W3
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.

As of Feb 24, 2008 if I use a P element instead of a SPAN element for the coordinates they fail in iexplore(1); yet I am already using a P element to display a single line. Is it the PRE element or the line feeds or something else? Does it not like nesting a PRE in a P? Simple tests would tell.

As of Feb 24, 2008 If you shrink the image small enough is vanishes in firefox(1), opera(1), and iexplore(1). It seems to occur about the time that the first AREA coordinates generate a polygon with zero area. Does the standard say that an image should not display if some or all of the targets cannot be reached (that is, if an image map is too small to fit all its targets?

Sections of the HTML 4 documentation

In the HTML4 specification at

http://www.w3.org/TR/html4/struct/objects.html

Sections 13.6.1 and 6.6 state that coordinates are lengths, and that lengths can be percents. So far, I have not found a browser that follows that specification.

6.6 Lengths

HTML specifies three types of length values for attributes:

Pixels: The value (%Pixels; in the DTD) is an integer that represents
the number of pixels of the canvas (screen, paper). Thus, the value "50"
means fifty pixels. For normative information about the definition of
a pixel, please consult [CSS1].

Length: The value (%Length; in the DTD) may be either a %Pixel; or a
percentage of the available horizontal or vertical space. Thus, the value
"50%" means half of the available space.
                   :
                   :
                   :
                   :


Note there is this odd definition in 13.6, which seems to imply that if you image is stretched so that circles appear as ellipses with unequal axis, that you should only use the area of the largest circle that fits in the ellipse? This seems like a very bad idea, especially since no similar requirement is made for distorted polygons or rectangles ...

circle: center-x, center-y, radius. 
Note. When the radius value is a percentage value, user agents should
calculate the final radius value based on the associated object's width
and height. The radius should be the smaller value of the two.

Other important statements

Coordinates are relative to the top, left corner of the object. All
values are lengths. All values are separated by commas.

If two or more defined regions overlap, the region-defining element
that appears earliest in the document takes precedence (i.e., responds
to user input).

Note that another section states a MAP can be used without an image. That being the case, another enhancement might be to allow the polygons to be rendered with a color attribute. This would allow you to create simple vector-based image maps.

The MAP element specifies a client-side image map (or other navigation
mechanism) that may be associated with another elements (IMG, OBJECT,
or INPUT). An image map is associated with an element via the element's
usemap attribute. The MAP element may be used without an associated
image for general navigation mechanisms.

Is the standard already implying the MAP data might be rendered graphically, or just as text?


Another natural enhancement seems to be one specifying that the opacity of a region change on a mouse-over. This would let you easily visually confirm the region selected.