Unresponsive image maps

[AndySky21]

https://html.spec.whatwg.org/multipage/embedded-content.html#processing-model

For historical reasons, the coordinates must be interpreted relative to the displayed image after any stretching caused by the CSS 'width' and 'height' properties

The text specifies that CSS cannot alter relative position of area elements. However, it does not detail how image maps can be built in a responsive way, i.e. how they can be associated to the new picture element, or simply how they can follow CSS resizing of relevant images.
This is a point that renders a very useful and widely supported feature completely useless in modern-day web applications.
Web developers have often resorted to resizing scripts in order to do that, there are quite a bunch of them in the wild. Why there is no native map resizing feature, or as an alternative how can this be obtained natively?

[zcorpan]

See ResponsiveImagesCG/picture-element#265

[AndySky21]

Almost one year has passed since the mentioned thread has been opened, I guess implementors have shown no interest in such issue. This is strange, as shape manipulation is already done in scaling vector images.
Do authors still have to resort to Flash, JS-based Canvas, difficult (i.e. not always applicable) and unresponsive SVG, and scaling scripts to achieve even a basic form of responsive image map?

[zcorpan]

SVG is not necessarily unresponsive, see analysis in https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Mar/0141.html

But yeah, nobody has shown interest in implementing this yet, AFAIK. That could change of course. Maybe file bugs on the browsers asking for this, email the various -dev mailing lists, or @mention relevant people here?

cc @yoavweiss

[AndySky21]

I guess that's a bit too much for me, as my project using image maps is still in development and I have nothing to show this issue on.
I hope someone catches more attention and changes that.

[prlbr]

As someone involved in the referenced discussions (in support of markup for responsive image maps), I think that the inline SVG solution works fine now that most browsers support it and will be even better once SVG 2.0 is finalized and supported (reducing the verbosity currently caused by having to use the xlink namespace a lot). So native HTML image maps seem largely redundant to me.

Nevertheless, I see a need for action:

I’d like to suggest to point to SVG as a modern and richer alternative in the part of the HTML spec that covers native HTML image maps (if there’s indeed no interest in modernizing them). Or else people will continue to dive deep into native HTML image maps and get frustrated when they find out that they have not been adapted to the requirements of today’s web … and this discussion will pop up rightly again and again.

[AndySky21]

I don't see anywhere in the spec that image maps as they are today are flagged as "outdated" or "deprecated". In fact, I just see that it's a feature which has not received enough attention. The fact that there are dozens of resizing script solutions in the wild underlines a need, from authors, to use them.
Yes, SVG is a richer solution. But in some cases it becomes, let's say, too rich. Not counting the fact that a single map element can be referred to by several images in the same page, which is sometimes quite useful. Nor counting the discrepancies in vendors support for SVG links (in some UAs, for what I know, hyperlinks are visually highlighted as rectangles even when they refer to other shapes, which is exactly what image maps are meant to avoid).
But there's more. Today HTML, with its picture-source-img solution, offers a good native feature for responsive images. Will SVG offer the same variety? Image maps are meant for those who have a predefined image (possibly not vectorial) with a map of hyperlinks associated to it. How can an author have several versions of the same image, all associated with the same map, in SVG?
IMHO I think that image maps should be updated, in order to continue living next to other solutions, so that authors can choose which one fits best to the project.
Today we have no SVG 2.0, nor we have native responsive image maps. I think that we're far from an optimal solution.

[prlbr]

Just to clarify, I wouldn’t mind native HTML image maps being updated to be responsive. And AndySky21 lists arguments which are worth considering. Modernized native HTML image maps could be a better/more efficient solution for real use cases. My point is that it would be advisable to guide people to the SVG alternative iff the reality is that there’s no interest by implementors for a modernized native HTML solution.

@AndySky21: SVG 2.0 isn’t a recommendation yet, but it’s clear that it will be.
http://www.w3.org/TR/SVG2/
http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap
Nevertheless SVG 1.1 does work today, it’s just more verbose.

[AndySky21]

In order to test vendors' interest there should be at least an idea of how "responsive maps" should work, I guess. It'd be also necessary to introduce a new attribute on image maps, not to break legacy compatibility (there would be issues for the maps resized via script, e.g.). This attribute should point out initial dimensions for the map (e.g. sizes="xx yy"), so that only maps with that attribute are resized by UAs, and resizing scales them according to horizontal/vertical stretch from initial dimensions. (unfortunately I think there should be a solution for non-proportional scaling of circles).

[zcorpan]

How can an author have several versions of the same image, all associated with the same map, in SVG?

You can use img/picture in SVG using foreignObject, as was pointed out in the email cited above.

my project using image maps is still in development and I have nothing to show this issue on.

The email also lists real-world examples where this feature would be helpful, fwiw.

[AndySky21]

ForeignObject is going to require an added level of complexity about syntax, instead of simplifying things, I guess.
However, can SVG provide a map solution for several distinct images on the same page, too?

[zcorpan]

I think not. But that is not a particular common need, is it?

I agree there are different pros and cons for the different approaches, and they all suck today. The question is should we make all of them slightly better, or focus on making only one better? I don't know, and personally I don't mind improving image maps, but there is little point in working on it in the spec if nobody wants to implement.

[AndySky21]

I understand now. Can anyone please tell me how to notify vendor dev forums about this thread or this particular need, so that they can tell what approach they're going to support?

[yoavweiss]

You may start a thread on https://discourse.wicg.io to get a better feel of the community's need for this particular feature. Demonstrating usage of current JS libraries that accomplish that can also be helpful to convince people that this is not a niche issue.

[zcorpan]

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.

[zcorpan]

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)

#514

[AndySky21]

@zcorpan has there been any development for points 3 and 4?

[zcorpan]

Nope. I'd like to wait for interoperable parsing of coords. And we still need impl interest for adding new features 🙂

[AndySky21]

The funny part is that, from a quick test, 4 modern browsers (Edge, Chrome, FF, Opera) apply CSS transform on image maps. So there has been an effort to modernize this feature.
Practically the only thing that has stopped implementors to apply CSS scaling to <map> element is the note I cited in my first message which forces client-side maps to be applied on images scaled via width/height properties.
Which also solves my issue, as an image map can be made responsive just using the transform:scale property.

[tabatkins]

Transforms working on image maps is not an intentional modernization of the feature. It's just that transforms work on all elements, and when you click on a transformed element it reports the click in "untransformed" coordinates, so image maps continue to work as expected.

[AndySky21]

I don't know exactly, but the map areas are not technically descendants of the scaled image itself.
In addition to this, IE/Edge and FF which show an outline for image maps on tab navigation, correctly outline scaled and transformed areas.

[prushforth]

@AndySky21 I have posted about progressive web maps, I would be curious to hear your comments. The areas in that map are responsive because the author has declared the size of the image via markup. Of course in the custom element I can't make the browser-managed areas responsive if the custom element isn't running.

[prushforth]

I'm confused by some of the conclusions here.

@AndySky21

Which also solves my issue, as an image map can be made responsive just using the transform:scale property.

I think this would be great, but I can't replicate it, and the HTML spec says that's by design:

Note: Browser zoom features and transforms applied using CSS or SVG do not affect the coordinates.

It would be great to have image maps being responsive, but the spec says that they should not be, for historical reasons:

For historical reasons, the coordinates must be interpreted relative to the displayed image after any stretching caused by the CSS 'width' and 'height' properties (or, for non-CSS browsers, the image element's width and height attributes — CSS browsers map those attributes to the aforementioned CSS properties).

I don't understand why this should prevent transforms embedded in media queries from working on the HTMLAreaElement.coords ? Those transformed coordinates could then be interpreted relative to the displayed image after stretching caused by width and height, which might work because the media condition that selected the image to display could be mirrored in a style that got processed before the image gets resized for the width and height. Pardon my lack of insight into the processing sequence here. I would like to help this get addressed.

[zcorpan]

@prushforth the spec codified what browsers did, under the assumption that there is web content that relies on that behavior. So changing it carries the risk of breaking web content, which would need to be researched somehow.

[zcorpan]

So looking at the bugs referenced in #514 (comment) the new coords parsing is implemented in Chromium and WebKit, but not yet in Gecko.