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.
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
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, 2008VALIDATE HTML5 VALIDATE W3
In the HTML4 specification at
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.
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.