Need for upgrading static image maps

Greeting to everybody. I’d like to discuss with authors an issue about image maps. The thought came to light when I realized that nowadays there is no way to make a native responsive image map (i.e. an image with hyperlinks associated to shaped areas of image itself). HTML spec is clear about that, and its implementation is consistent across legacy and modern user agents: HTML image maps built with a <map> element are not affected by CSS. That’s all.

As I discovered soon, the fact that “image maps” are not responsive is not entirely true, as a similar result can be obtained through SVG. Of course I mean inline SVG, as including it as an <img src=""> attribute would disable hyperlinks, and iframe/object element would not allow the embedded document to be resized. I consider SVG a powerful tool for the purpose it was created to fulfill, but from a theoretical perspective, recurring to it in order to accomplish a native HTML goal seems weird. But there’s more. SVG syntax for such a construct involves having: the SVG subtree, an element for the image and a double series of elements for map areas. A double series, because each area has to be represented with a shape nested inside an <a> element. This is not going to change, of course, as SVG shapes are not meant to be hyperlinks and therefore will not have a href attribute. The only change in perspective, for what matters, is that SVG 2.0 is going to have an <a> element on its own (without recurring to xlink language). Also consider that some user agents interpret incorrectly hyperlink “box” borders, especially when more than one shape is nested inside one <a> element.

Of course SVG allows the application of CSS, so that it can be used not only for responsive images, but probably also in CSS transform context.

About responsive images, though, I can go a little bit further. HTML today provides authors a new powerful method for embedding adaptive images: the <picture> element. In order to use this feature with SVG for responsive maps with adaptive “context” images, though, a <foreignElement> tag is to be used inside SVG in order to include a element. This complicates the SVG map subtree even further.

What we are left with, today, is a <map> element that looks as it was included in living standard for a matter of backward compatibility, and an inefficient way to achieve the purpose for which the map element was meant. And the map element does it neatly (the subtree is ridiculously simple), easily (shapes are essential and consistent to define) and with the advantage of being able to apply the same image map to several images inside a single page. Yes, SVG can be used to produce a similar result. But the <map> element can be a compact, native alternative for it.

The web is full of examples of JS scripts for making image map elements responsive. Unfortunately I suppose they will fail in applying CSS transform to <map> elements, or to make them work with <picture> elements.

I proposed this issue to HTML Working Group as a specification bug, though it isn’t properly a bug. I was replied that there were no community/vendor interest about that. I don’t know whether this has ever been proposed, considered and/or discarded.

I’d like to know what people and vendors think about 3 aspects of the <map> element “upgrade”.

1. the map element is to be made responsive to CSS resizing/transform applied on context image.
2. the map element is to be extended to <picture> elements, so it can work with adaptive images.
3. CSS should apply to map element shapes in order to make them more interactive.

From the bug I filed to HTML spec on GitHub you can follow links to the original HTML mailing list thread, including objections and example use cases:
Unresponsive image maps · Issue #389 · whatwg/html

In the Maps for HTML Community Group, we are partially motivated by similar concerns about the HTML map element.

Our objective is to develop a responsive web map element specification, and hopefully, eventually an element that supports cartographic applications.

Have a look at the (custom element) prototype page, which has links to the spec, github repos, the community home page etc. Does that resemble what your needs are? If so, you should join the Maps4HTML CG. Also, please note that there is a web-mapping category on this forum, and it would be great to have discussion of the Maps4HTML work in there as well. I have invited and will continue to invite the Web mapping community to discuss standards issues there, and yours seems to fit that concept, depending on what you’re doing with your image maps. Thank you for this post.

SVG is HTML, for all intents and purposes. There’s no reason to be afraid of using it.

You are right, I was not precise when I talked about recurring to a different “language”. But you have to recognize that a SVG image map syntax is a little bit harder than native maps.

In addition to this, the possible integration of SVG image maps with HTML <picture> element passes through the <foreignElement> tag, so the distinction remains significant. Al least until all SVG elements lose their content model specificity or in case <picture> is defined in the SVG 2.0 spec too.

SVG is a great language for defining scalable vector images. But probably “easier” image map constructs could benefit of a lower level of complexity.

The <picture> limitations are only temporary. The plan of record is to add srcset to <svg:image>, and let the HTML <picture> and <source> elements be used directly in SVG around an <svg:image>, just like they’re used in HTML around an <img>. Then there’s no need to indirect through a <foreignContent>.

I just hope that, together with these plans for SVG, an interest for the <map> element being upgraded can be tested with this thread.

As you said, this is a plan. It seems that using SVG will allow a much wider set of options, but still, as <map> is not flagged as “obsolete” or “deprecated”, I guess that there should be plans for it, too.

Related comment from @zcorpan on the HTML GH issue:

Here’s a plan:

• Change coords parsing to be more in line with gecko/blink/webkit instead of IE (bug 28148)
• Actually support non-integers in coords (maybe not really necessary but why not)
• Address use case (1) from the email by adding width and height attributes to map, which give the coordinate space, and this coordinate space is then stretched to fit the image. (This should make it easy to make image maps responsive; just copy the width/height attributes from the img and you’re done, no need to rewrite the coordinates to percentages or anything. It’s also feature-testable.)
• If the above is successful and we also want to address use case (2) from the email, add a usemap attribute to source, and switch image map when images switch.