Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unresponsive image maps #389

Open
AndySky21 opened this issue Dec 9, 2015 · 24 comments
Open

Unresponsive image maps #389

AndySky21 opened this issue Dec 9, 2015 · 24 comments
Labels
addition/proposal New features or enhancements needs compat analysis needs implementer interest Moving the issue forward requires implementers to express interest

Comments

@AndySky21
Copy link

@AndySky21 AndySky21 commented Dec 9, 2015

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 zcorpan added the needs implementer interest Moving the issue forward requires implementers to express interest label Dec 9, 2015
@zcorpan
Copy link
Member

@zcorpan zcorpan commented Dec 9, 2015

@AndySky21
Copy link
Author

@AndySky21 AndySky21 commented Dec 9, 2015

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
Copy link
Member

@zcorpan zcorpan commented Dec 9, 2015

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
Copy link
Author

@AndySky21 AndySky21 commented Dec 9, 2015

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
Copy link

@prlbr prlbr commented Dec 9, 2015

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
Copy link
Author

@AndySky21 AndySky21 commented Dec 9, 2015

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
Copy link

@prlbr prlbr commented Dec 9, 2015

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
Copy link
Author

@AndySky21 AndySky21 commented Dec 9, 2015

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
Copy link
Member

@zcorpan zcorpan commented Dec 9, 2015

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
Copy link
Author

@AndySky21 AndySky21 commented Dec 9, 2015

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
Copy link
Member

@zcorpan zcorpan commented Dec 9, 2015

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
Copy link
Author

@AndySky21 AndySky21 commented Dec 14, 2015

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
Copy link
Collaborator

@yoavweiss yoavweiss commented Dec 15, 2015

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
Copy link
Member

@zcorpan zcorpan commented Dec 21, 2015

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
Copy link
Member

@zcorpan zcorpan commented Jan 14, 2016

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

@domenic domenic added the addition/proposal New features or enhancements label Apr 22, 2016
@AndySky21
Copy link
Author

@AndySky21 AndySky21 commented Sep 13, 2016

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

@zcorpan
Copy link
Member

@zcorpan zcorpan commented Sep 13, 2016

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

@AndySky21
Copy link
Author

@AndySky21 AndySky21 commented Sep 13, 2016

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
Copy link
Collaborator

@tabatkins tabatkins commented Sep 13, 2016

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
Copy link
Author

@AndySky21 AndySky21 commented Sep 13, 2016

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
Copy link

@prushforth prushforth commented Oct 3, 2016

@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
Copy link

@prushforth prushforth commented Oct 2, 2019

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
Copy link
Member

@zcorpan zcorpan commented Jun 18, 2020

@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
Copy link
Member

@zcorpan zcorpan commented Jun 18, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements needs compat analysis needs implementer interest Moving the issue forward requires implementers to express interest
Development

No branches or pull requests

7 participants