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
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
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”.
- the map element is to be made responsive to CSS resizing/transform applied on context image.
- the map element is to be extended to
<picture>elements, so it can work with adaptive images.
- 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