Re: [whatwg] Responsive image maps
The active area in the svg is whatever the active graphical shape is, I don't quite understand what you mean that it's unclear. The active shape can also be styled with css based on :hover or :active rules, for example to add an outline or to do some sort of visual highlighting. For controlling the tab order there's the tabindex attribute (added in svg2), which has the same behavior as in html. Tabbing through an svg probably works best if the svg is inline in the html document. Support for tabindex in svg is implemented in Blink and WebKit already. On Wed, 25 Mar 2015 21:24:04 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: One of the 2 objections, I'd say. But the second is probably a matter of implementation. SVG makes it unclear what's the actual active area when navigating through tab key. 2015-03-25 19:32 GMT+01:00 Tab Atkins Jr. jackalm...@gmail.com: On Wed, Mar 25, 2015 at 10:03 AM, Andrea Rendine master.skywalker...@gmail.com wrote: Instead, we start by figuring out what problems need solving. Which is what has been done for this subject, I guess. PROBLEM: image maps, intended as shaped link areas related to specific regions of an image are a fairly requested feature. Unfortunately, as current solutions are not responsive and they can't fit to how images are defined in a modern scenario, with scalable size and art direction, authors have looked for workarounds, script-enhanced or non-native (Flash maps) solutions. POSSIBLE SOLUTIONS: 1. link boxes and CSS, 2. SVG, 3. map, where 1. CSS has a poor range of shapes 2. See above for SVG 3. area coordinates are absolutely defined. PROPOSAL: As SVG map is not viable at all in complex picture scenarios, and not easily viable in simple contexts, authors could benefit from map versatility. So a viable solution *could* be to improve a feature in order to make it responsive. The Map element improvement consortium is not an organisation I want to mindlessly support (basically because it doesn't exists). And unfortunately I tend to be verbose when I start writing. So in my last message I tried to make it shorter and I chose terms incorrectly. Note that we *should* just be able to use picture in SVG, which helps that solution. This is generally useful (we want responsive images inside of SVG, too), and afaict, removes the only objection to SVG. ~TJ -- Erik Dahlstrom, Web Technology Developer, Opera Software Co-Chair, W3C SVG Working Group
Re: [whatwg] Responsive image maps
The active area in the svg is whatever the active graphical shape is, I don't quite understand what you mean that it's unclear The main difference between native SVG implementation and native area implementation (map/area scenario lets you small room for maneuvering, so it's native anyway) is that image maps, using tab navigation, don't expose active area. On Chrome there's a large rectangle highlighting the area (or areas in case of link spanning over multiple items), on every other platform there's no native highlighting at all. It's true, you can do it with CSS, but in image maps it's already implemented. As said, it's only a matter of implementation though. Going further, it will be redefined. The fact is always the same: as it's all a matter of implementation, I strongly believe that a mean of natively resize maps should be implemented anyway. You are right, SVG is more flexible with CSS and JS support, but flexibility comes with a cost: those rules have to be defined. Tabbing through an svg probably works best if the svg is inline in the html document For the purpose of this thread, embedded SVG simply wouldn't make any sense. We are talking about links connected with the subject of the document, it goes over the purpose of the image itself (see my note about relative paths above, too). However, there's another point, which IDK if can matter. Maps can be included at any point of the document. With some CSS they can be used as out-of-context item lists, and they can also be reused for different maps inside an image, while SVG have to be repeated. 2015-03-31 16:02 GMT+02:00 Erik Dahlström e...@opera.com: The active area in the svg is whatever the active graphical shape is, I don't quite understand what you mean that it's unclear. The active shape can also be styled with css based on :hover or :active rules, for example to add an outline or to do some sort of visual highlighting. For controlling the tab order there's the tabindex attribute (added in svg2), which has the same behavior as in html. Tabbing through an svg probably works best if the svg is inline in the html document. Support for tabindex in svg is implemented in Blink and WebKit already. On Wed, 25 Mar 2015 21:24:04 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: One of the 2 objections, I'd say. But the second is probably a matter of implementation. SVG makes it unclear what's the actual active area when navigating through tab key. 2015-03-25 19:32 GMT+01:00 Tab Atkins Jr. jackalm...@gmail.com: On Wed, Mar 25, 2015 at 10:03 AM, Andrea Rendine master.skywalker...@gmail.com wrote: Instead, we start by figuring out what problems need solving. Which is what has been done for this subject, I guess. PROBLEM: image maps, intended as shaped link areas related to specific regions of an image are a fairly requested feature. Unfortunately, as current solutions are not responsive and they can't fit to how images are defined in a modern scenario, with scalable size and art direction, authors have looked for workarounds, script-enhanced or non-native (Flash maps) solutions. POSSIBLE SOLUTIONS: 1. link boxes and CSS, 2. SVG, 3. map, where 1. CSS has a poor range of shapes 2. See above for SVG 3. area coordinates are absolutely defined. PROPOSAL: As SVG map is not viable at all in complex picture scenarios, and not easily viable in simple contexts, authors could benefit from map versatility. So a viable solution *could* be to improve a feature in order to make it responsive. The Map element improvement consortium is not an organisation I want to mindlessly support (basically because it doesn't exists). And unfortunately I tend to be verbose when I start writing. So in my last message I tried to make it shorter and I chose terms incorrectly. Note that we *should* just be able to use picture in SVG, which helps that solution. This is generally useful (we want responsive images inside of SVG, too), and afaict, removes the only objection to SVG. ~TJ -- Erik Dahlstrom, Web Technology Developer, Opera Software Co-Chair, W3C SVG Working Group
Re: [whatwg] Responsive image maps
On Thu, 26 Mar 2015 01:47:57 +0100, Martin Janecke whatwg@prlbr.com wrote: Am .03.2015, 16:08 Uhr, schrieb Simon Pieters sim...@opera.com: […] It seems to me that there are two use cases: 1. variable-size image map 2. art direction image map (1) is more common than (2). Yes, you're right. If there is implementor interest, I think it makes sense to make map address use case (1) first, and after that maybe also use case (2). Is there? :-) I'd say there's a good chance that a solution for (1) could also cover (2). So it might be helpful to keep (2) in mind while working on (1) in order not to miss that chance … If there is implementor interest. How? Consider the AMC Networks image map in the footer of http://www.wetv.com/ . Make the window narrower than 600px, the image map will have a different layout. -- Simon Pieters Opera Software
Re: [whatwg] Responsive image maps
Am .03.2015, 11:10 Uhr, schrieb Simon Pieters sim...@opera.com: On Thu, 26 Mar 2015 01:47:57 +0100, Martin Janecke whatwg@prlbr.com wrote: Am .03.2015, 16:08 Uhr, schrieb Simon Pieters sim...@opera.com: […] It seems to me that there are two use cases: 1. variable-size image map 2. art direction image map (1) is more common than (2). Yes, you're right. If there is implementor interest, I think it makes sense to make map address use case (1) first, and after that maybe also use case (2). Is there? :-) I'd say there's a good chance that a solution for (1) could also cover (2). So it might be helpful to keep (2) in mind while working on (1) in order not to miss that chance … If there is implementor interest. How? Consider the AMC Networks image map in the footer of http://www.wetv.com/ . Make the window narrower than 600px, the image map will have a different layout. Ah, I see. I didn't understand correctly what art direction meant here. Mea culpa.
Re: [whatwg] Responsive image maps
On Tue, 24 Mar 2015 15:41:26 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: why not improving an existing feature instead of finding so many expensive workarounds? It'd allow authors the choice to use between 2 different tools for different cases. See https://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94 I think many people consider map to be a legacy feature [1], where the primary goal is interop and compat with Web content. Changing such features means moving away from interop, and risk breaking Web content. Therefore, improvements of such features have a higher barrier compared to improvements of newer, better designed features. In this case, I think it is possible to extend map to address the use cases without regressing interop or breaking Web content, and there is demonstrated need from Web developers. The missing piece is positive signals from browser vendors. [1] The only new feature I'm aware of since HTML4 is HTMLMapElement#images. This feature has not been implemented by anyone, so unless somone suddenly shows interest implementing it, it will most likely be removed again. https://www.w3.org/Bugs/Public/show_bug.cgi?id=28219 -- Simon Pieters Opera Software
Re: [whatwg] Responsive image maps
why not improving an existing feature See https://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94 Yes, I think I should have expressed it better. Why not improving *this* specific feature? I'm aware that older elements could end up being incompatible with use cases they have served as of now. That's why, instead of changing something, I guess it's better to *add* something, so that legacy UAs keep on behaving as they can (and probably rely on polyfill) while compliant browsers treat new features (elements, attributes, etc.) properly. You can see my original idea at the beginning of this thread. What I proposed is to add an attribute to map element, let's say viewbox or sizes. This attribute shows the width and height (properly separated by space or comma) for which areas coordinates are intended. E.g. map id=resizable name=resizable viewbox=640 480 area href=rectangle.html type=rect coords=0,0,320,120 / /map Now, suppose this map is applied to an image resized to 800x720. areas have to be resized as well, according to proper ratios. So horizontal coordinates (odd positions in the coords list) are to be stretched them by (800/640) = 1.25 times, while vertical coordinates (even positions in the list) by (720/480) = 1.5 (just to handle cases where the original image ratio is stretched). So the adjusted coordinates would be (0*1.25,0*1.5,320*1.25,120*1.5) = (0,0,400,150). As said, the only problem would be with circles which should be stretched into ellipses when ratios are not equal. - resizing does not apply on old maps (without this attribute) and they probably rely on resizing scripts. - maps provided with viewbox attribute are resized natively on compliant UAs. - there should be an associated property to be recognized, so that polyfill support can be provided on new maps *only* in those browsers which do not know how to handle @viewbox and the resizing mechanism. I hope it can be done as easily as it can be described.
Re: [whatwg] Responsive image maps
On Wed, Mar 25, 2015 at 3:21 PM, Andrea Rendine master.skywalker...@gmail.com wrote: Yes, I think I should have expressed it better. Why not improving *this* specific feature? That's generally not how we do things. We don't start looking at an existing set of features and figure out how we can add some flair. Instead, we start by figuring out what problems need solving. You might want to study the rest of the FAQ and in particular: https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F -- https://annevankesteren.nl/
Re: [whatwg] Responsive image maps
Instead, we start by figuring out what problems need solving. Which is what has been done for this subject, I guess. PROBLEM: image maps, intended as shaped link areas related to specific regions of an image are a fairly requested feature. Unfortunately, as current solutions are not responsive and they can't fit to how images are defined in a modern scenario, with scalable size and art direction, authors have looked for workarounds, script-enhanced or non-native (Flash maps) solutions. POSSIBLE SOLUTIONS: 1. link boxes and CSS, 2. SVG, 3. map, where 1. CSS has a poor range of shapes 2. See above for SVG 3. area coordinates are absolutely defined. PROPOSAL: As SVG map is not viable at all in complex picture scenarios, and not easily viable in simple contexts, authors could benefit from map versatility. So a viable solution *could* be to improve a feature in order to make it responsive. The Map element improvement consortium is not an organisation I want to mindlessly support (basically because it doesn't exists). And unfortunately I tend to be verbose when I start writing. So in my last message I tried to make it shorter and I chose terms incorrectly. Cheers, AR
Re: [whatwg] Responsive image maps
On Wed, Mar 25, 2015 at 10:03 AM, Andrea Rendine master.skywalker...@gmail.com wrote: Instead, we start by figuring out what problems need solving. Which is what has been done for this subject, I guess. PROBLEM: image maps, intended as shaped link areas related to specific regions of an image are a fairly requested feature. Unfortunately, as current solutions are not responsive and they can't fit to how images are defined in a modern scenario, with scalable size and art direction, authors have looked for workarounds, script-enhanced or non-native (Flash maps) solutions. POSSIBLE SOLUTIONS: 1. link boxes and CSS, 2. SVG, 3. map, where 1. CSS has a poor range of shapes 2. See above for SVG 3. area coordinates are absolutely defined. PROPOSAL: As SVG map is not viable at all in complex picture scenarios, and not easily viable in simple contexts, authors could benefit from map versatility. So a viable solution *could* be to improve a feature in order to make it responsive. The Map element improvement consortium is not an organisation I want to mindlessly support (basically because it doesn't exists). And unfortunately I tend to be verbose when I start writing. So in my last message I tried to make it shorter and I chose terms incorrectly. Note that we *should* just be able to use picture in SVG, which helps that solution. This is generally useful (we want responsive images inside of SVG, too), and afaict, removes the only objection to SVG. ~TJ
Re: [whatwg] Responsive image maps
One of the 2 objections, I'd say. But the second is probably a matter of implementation. SVG makes it unclear what's the actual active area when navigating through tab key. 2015-03-25 19:32 GMT+01:00 Tab Atkins Jr. jackalm...@gmail.com: On Wed, Mar 25, 2015 at 10:03 AM, Andrea Rendine master.skywalker...@gmail.com wrote: Instead, we start by figuring out what problems need solving. Which is what has been done for this subject, I guess. PROBLEM: image maps, intended as shaped link areas related to specific regions of an image are a fairly requested feature. Unfortunately, as current solutions are not responsive and they can't fit to how images are defined in a modern scenario, with scalable size and art direction, authors have looked for workarounds, script-enhanced or non-native (Flash maps) solutions. POSSIBLE SOLUTIONS: 1. link boxes and CSS, 2. SVG, 3. map, where 1. CSS has a poor range of shapes 2. See above for SVG 3. area coordinates are absolutely defined. PROPOSAL: As SVG map is not viable at all in complex picture scenarios, and not easily viable in simple contexts, authors could benefit from map versatility. So a viable solution *could* be to improve a feature in order to make it responsive. The Map element improvement consortium is not an organisation I want to mindlessly support (basically because it doesn't exists). And unfortunately I tend to be verbose when I start writing. So in my last message I tried to make it shorter and I chose terms incorrectly. Note that we *should* just be able to use picture in SVG, which helps that solution. This is generally useful (we want responsive images inside of SVG, too), and afaict, removes the only objection to SVG. ~TJ
Re: [whatwg] Responsive image maps | inline SVGs in general
Am .03.2015, 12:50 Uhr, schrieb Andrea Rendine master.skywalker...@gmail.com: […] IE11 doesn't scale SVG as noticed about previous versions. Thanks Andrea (also for your further feedback on the test cases), that is good to know. Am .03.2015, 14:36 Uhr, schrieb Erik Dahlström e...@opera.com: On Sun, 22 Mar 2015 15:06:40 +0100, Martin Janecke whatwg@prlbr.com wrote: I've done a few tests and provide links to them below the following discussion. ... Test 4: https://prlbr.de/2015/03/inline-svg-without-height.html Test 5: https://prlbr.de/2015/03/inline-svg-without-size.html Test 4 is almost identical to test 3, but I haven't specified a height on the the SVG element this time. Test 5 has neither height nor width specified for the SVG and always gets its size by fitting in the surrounding figure element. Both tests work as expected in FF, Opera, Safari and Chrome. IE9 doesn't get the size right. Test 5 is the proper way to do this IMHO. A workaround for the bug in IE9+ is to add a wrapper element that does the responsive sizing. Something along the lines of http://jsfiddle.net/vo1ofz0w/1/. That's very helpful in practice, thanks! It didn't work 100% correctly yet (it pushes the figcaption away when the window is bigger than 800px) but was easy to fix. (https://prlbr.de/2015/03/inline-svg-without-height.html) I feel like this absolute positioning and border-bottom=(100% divided by image aspect ratio) trick is a kludge though. It's nice to have to make things work now, but it's not what I'd want to teach anyone as a good way to do it. So I wonder why the browser behavior is still so inconsistent about including inline SVGs that this is necessary, although inline SVGs have officially been supported by browsers for years (http://caniuse.com/svg-html5). And it's not only IE. Opera, Safari, Chrome also behaved differently than Firefox in my third test. Is the integration of inline SVGs (such as their display size, which measures [CSS in the HTML part, SVG element attributes, CSS within SVG] take precedence) right at the interface between HTML+CSS and inline SVG spec'ed? The HTML spec hardly says anything (https://html.spec.whatwg.org/multipage/embedded-content.html#svg-0) about it. Where do I have to look in the SVG spec to find something about it? Or is it in a CSS spec? If it isn't defined neither explicitly nor implicitly (e.g. by some general convention for cases that are not explicitly described) yet, I suggest defining it. We can see right now how browsers do it, analyze which way makes most sense and standardize it. I think this is quite important – definitely not only for inline SVG's possible application as image map as originally discussed in this thread, but for every use of inline SVGs. Therefore I'd start a new thread if there's indeed a lack of standardization here. Martin
Re: [whatwg] Responsive image maps | inline SVGs in general
A workaround for the bug in IE9+ is to add a wrapper element that does the responsive sizing. Something along the lines of http://jsfiddle.net/vo1ofz0w/1/. That's very helpful in practice, thanks! It didn't work 100% correctly yet (it pushes the figcaption away when the window is bigger than 800px) but was easy to fix. (https://prlbr.de/2015/03/inline-svg-without-height.html) Sorry, the correct link for this is: https://prlbr.de/2015/03/inline-svg-with-container.html Martin
Re: [whatwg] Responsive image maps
Am .03.2015, 16:08 Uhr, schrieb Simon Pieters sim...@opera.com: […] It seems to me that there are two use cases: 1. variable-size image map 2. art direction image map (1) is more common than (2). Yes, you're right. If there is implementor interest, I think it makes sense to make map address use case (1) first, and after that maybe also use case (2). Is there? :-) I'd say there's a good chance that a solution for (1) could also cover (2). So it might be helpful to keep (2) in mind while working on (1) in order not to miss that chance … If there is implementor interest. Martin
Re: [whatwg] Responsive image maps
On Sun, 22 Mar 2015 15:06:40 +0100, Martin Janecke whatwg@prlbr.com wrote: I've done a few tests and provide links to them below the following discussion. ... Test 4: https://prlbr.de/2015/03/inline-svg-without-height.html Test 5: https://prlbr.de/2015/03/inline-svg-without-size.html Test 4 is almost identical to test 3, but I haven't specified a height on the the SVG element this time. Test 5 has neither height nor width specified for the SVG and always gets its size by fitting in the surrounding figure element. Both tests work as expected in FF, Opera, Safari and Chrome. IE9 doesn't get the size right. Test 5 is the proper way to do this IMHO. A workaround for the bug in IE9+ is to add a wrapper element that does the responsive sizing. Something along the lines of http://jsfiddle.net/vo1ofz0w/1/. Test 6: https://prlbr.de/2015/03/html-img-with-svg.html Here I've referenced the SVG (as defined in test 5) with an img element instead of including it inline. This doesn't work in any browser. Except for IE9 the browsers don't even show the included photograph. IE9 shows the photograph, but neither links nor tooltips work. Due to privacy security concerns, an svg will not fetch any external content when it is referenced by an img element. ... However, the HTML living standard features the picture element to allow authors to declaratively control or give hints to the user agent about which image resource to use, based on the screen pixel density, viewport size, image format, and other factors (https://html.spec.whatwg.org/multipage/embedded-content.html#the-picture-element). The SVG solution discussed above references the image by a different SVG mechanism. Note that it's perfectly fine to reference svg files from a picture element, see e.g http://sarasoueidan.com/blog/svg-picture/. -- Erik Dahlstrom, Web Technology Developer, Opera Software Co-Chair, W3C SVG Working Group
Re: [whatwg] Responsive image maps
Note that it's perfectly fine to reference svg files from a picture element, see e.g http://sarasoueidan.com/blog/svg-picture/. Which means repeating the map construction for every SVG file. Of course if the SVG is created by a script or a graphics application it can be done easily, but this is not always the case. However, before this discussion about SVG goes too far, and also keeping in mind some limitations of SVG itself (as I said before), I ask again: why not improving an existing feature instead of finding so many expensive workarounds? It'd allow authors the choice to use between 2 different tools for different cases. 2015-03-24 14:36 GMT+01:00 Erik Dahlström e...@opera.com: On Sun, 22 Mar 2015 15:06:40 +0100, Martin Janecke whatwg@prlbr.com wrote: I've done a few tests and provide links to them below the following discussion. ... Test 4: https://prlbr.de/2015/03/inline-svg-without-height.html Test 5: https://prlbr.de/2015/03/inline-svg-without-size.html Test 4 is almost identical to test 3, but I haven't specified a height on the the SVG element this time. Test 5 has neither height nor width specified for the SVG and always gets its size by fitting in the surrounding figure element. Both tests work as expected in FF, Opera, Safari and Chrome. IE9 doesn't get the size right. Test 5 is the proper way to do this IMHO. A workaround for the bug in IE9+ is to add a wrapper element that does the responsive sizing. Something along the lines of http://jsfiddle.net/vo1ofz0w/1/. Test 6: https://prlbr.de/2015/03/html-img-with-svg.html Here I've referenced the SVG (as defined in test 5) with an img element instead of including it inline. This doesn't work in any browser. Except for IE9 the browsers don't even show the included photograph. IE9 shows the photograph, but neither links nor tooltips work. Due to privacy security concerns, an svg will not fetch any external content when it is referenced by an img element. ... However, the HTML living standard features the picture element to allow authors to declaratively control or give hints to the user agent about which image resource to use, based on the screen pixel density, viewport size, image format, and other factors ( https://html.spec.whatwg.org/multipage/embedded-content. html#the-picture-element). The SVG solution discussed above references the image by a different SVG mechanism. Note that it's perfectly fine to reference svg files from a picture element, see e.g http://sarasoueidan.com/blog/svg-picture/. -- Erik Dahlstrom, Web Technology Developer, Opera Software Co-Chair, W3C SVG Working Group
Re: [whatwg] Responsive image maps
On Fri, 20 Mar 2015 20:22:28 +0100, Martin Janecke whatwg@prlbr.com wrote: Am .03.2015, 13:10 Uhr, schrieb Simon Pieters sim...@opera.com: Please leave out syntax proposals for now. What I think is needed first to drive this forward is: * Use cases. Why do you need this? In general it's needed to allow geometric areas on an image to be associated with hyperlinks – that's what https://html.spec.whatwg.org/multipage/embedded-content.html#image-map says – and to associate areas on an image with tooltips. I've used this to name objects in a drawing (think of helping children or foreigners learn words for things displayed in an image). I've also packed small versions of photographs with different aspect ratios nicely aligned in a single preview image file and used an image map to link those previews with bigger sized photographs (https://prlbr.de/2014/wanderung-wanzer-wittenberge/). I've seen Wikipedia link objects in photographs and paintings (star constellations, people) with active image areas. It's also used for site navigation with fancy design. Those are use cases for image maps. Having them work on different screen sizes, e.g. on smartphones and desktop screens, is the main use case for making them responsive. Thanks. * More examples of pages that work around the lack of this feature. Here's a Wordpress plugin actively used on 7000+ sites: https://wordpress.org/plugins/responsive-image-maps/ In httparchive I see 92 out of ~130,000 pages using jquery.rwdImageMaps.min.js or imageMapResizer.min.js. SELECT page, COUNT(*) as num FROM [httparchive:runs.2014_08_15_requests_body] WHERE REGEXP_MATCH(body, r'(jquery\.rwdImageMaps\.min\.js|imageMapResizer\.min\.js)') GROUP BY page ORDER BY num desc; Of those 92, 17 use variable-size image map: http://www.shitlicious.com/ http://www.1stonlinesolutions.com/ http://www.audio-technica.com/world_map/ http://www.apartmentratings.com/ http://www.unoriginalmom.com/ http://www.bonton.fr/en_4/ https://www.electricobjects.com/ http://www.zeitzuleben.de/ https://www.konami.com/ https://www.ncjrs.gov/ http://www.thehybridshop.com/ http://www.brief.pl/ http://www.foodpolitics.com/ http://www.milegi.in/ http://www.sura.com/internacional/default.aspx http://www.mintvelvet.co.uk/ http://www.oldtimecandy.com/ ...and 3 use art direction image map: http://www.wetv.com/ http://www.kidsii.com/ http://www.hbs.edu/Pages/default.aspx ...and the rest either don't use map at all or use a fixed-width image map. Recently I've modified my personal website to be mobile-friendly – except for all the pages that use image maps with differently shaped active areas, because I didn't have a nice solution for these. That's not an example for a work-around of course, but an example for demand for such a feature. Here's a bunch of stackoverflow questions showing more demand: http://stackoverflow.com/questions/1563299/recalculate-image-map-after-window-resize http://stackoverflow.com/questions/7844399/responsive-image-map http://stackoverflow.com/questions/7943003/dynamically-resizing-image-maps http://stackoverflow.com/questions/12214373/image-mapping-responsive-design http://stackoverflow.com/questions/13321067/dynamically-resizing-image-maps-and-images http://stackoverflow.com/questions/20058971/dynamically-resizing-image-maps-and-images-maphilight-min-js http://stackoverflow.com/questions/23752408/resizing-image-maps-containing-circles http://stackoverflow.com/questions/25806090/how-to-detect-and-change-polygon-shape-co-ordinates-in-image-to-be-responsive http://stackoverflow.com/questions/26298771/how-would-i-create-a-dynamic-hit-zone-that-changes-when-resizing-or-moving-the http://stackoverflow.com/questions/26552283/html-image-map-areas-responsiveness These all appear to want to use variable-size image maps. * Why are alternatives like CSS-positioned a links […] not better? Unlike a elements, areas in an image map can be shaped as a circle or as an author-defined polygon. That's essential when describing parts of certain images. I was going to say that CSS shapes allows other shapes, but apparently it doesn't affect hit testing. * Why are alternatives like […] SVG not better? I didn't know SVG could be used for this. This is new to me, so I'm not sure yet, but it looks quite good. Should the outcome of this discussion be that SVG is good enough to solve all use cases and that image maps are not enhanced, I'd suggest adding a hint to SVGs as a note in the image map section of the HTML spec. Yeah, we could do that in any case. However, since image maps have been an integral part of HTML since version 3.2 and not been deprecated in favor of a better alternative yet, it might still be a straightforward solution to enhance them. Responsive image maps would be backwards compatible to all non-graphical clients that support at least HTML 3.2 such as Lynx, various bots and presumably
Re: [whatwg] Responsive image maps
My idea started from considerations about the picture element itself, so I agree with Martin, a native feature to resize image maps should wrk with the picture/img scenario. IE11 doesn't scale SVG as noticed about previous versions. As a side note, I have to notice that selecting areas in SVG with tab navigation behaves inconsistently. (tested on Chrome, Opera, FF, IE latest versions at the time of writing): - Chrome highlights the active regions with rectangles encompassing the areas. Note that if the area is a non-rectangular polygon, or a circle, or worse a group of areas, the highlighted region will also include non-active areas and I don't know how confusing it can be. - Opera does not allow tab navigation on the examples provided by Martin. IDK if it needs tabindex as well, but simple examples can be navigated only with click. - FF and IE allow tab navigation, but they don't highlight regions at all. On the other hand, in map scenario only the area is highlighted instead, and with the correct shape, in all user agents. Side note #2: the correct syntax is a xlink:href=, as done in Martin's examples, not a href, as @href is not a native attribute of SVG for what I know. It seems that using SVG with a elements is an adaptation of an existing element for a different purpose. It is useful in some scenarios, especially when the image itself is generated in SVG and associated with links (and maybe other visual hints/effects directly applied on SVG elements), but map is the native feature to do so, it's usable, it's also user-friendly though it has limitations. It would probably be better to make it more modern and allow authors to choose as they prefer. 2015-03-22 15:06 GMT+01:00 Martin Janecke whatwg@prlbr.com: I've done a few tests and provide links to them below the following discussion. Am .03.2015, 20:30 Uhr, schrieb Tab Atkins Jr. jackalm...@gmail.com: SVG is highly accessible. Yes, SVG a elements are followed just like HTML a elements, and yes, screenreaders do read out desc elements when appropriate. Nice! Am .03.2015, 21:15 Uhr, schrieb Tab Atkins Jr. jackalm...@gmail.com: On Fri, Mar 20, 2015 at 1:00 PM, Andrea Rendine master.skywalker...@gmail.com wrote: About SVG, I made a couple of tests and they are far from being comprehensive, but this is the fact. SVG image maps need to define 2 elements for each area, i.e. the element itself and its associated hyperlink. That's really not much: svg width=... height=... image src=foo ... / a href=target1polygon points=... //a a href=target2rect ... //a ... /svg The markup complexity seems to be about the same as using img/map/area, especially if you accompany it with prose like the example in https://html.spec.whatwg.org/multipage/embedded-content. html#the-map-element shows. While inline SVGs are somewhat more verbose and complex, I'd say it's justifiable. They also bring advantages like being able to link multiple disconnected areas to a single resource with a single hyperlink. svg elements can be resized by the CSS 'width' and 'height' properties just fine. Yes, though my third test showed an inconsistency that might need to be addressed. .: Tests :. I've done tests with Internet Explorer 9 (IE9), Opera 27 (Opera) on Windows Vista and Firefox 36 (FF), Google Chrome 41 (Chrome), Safari 8 (Safari) on Mac OS 10.10. All test pages show a photograph of a dog and a few items lying on the floor. The goal is to display the photo with 800px × 600px in windows that are larger and have the photo resize automatically in smaller windows, so that there's no horizontal scrolling necessary. The dog and all the shoes in the photo are active areas: they are supposed to show tooltips when hovered and lead to the Wikipedia articles Dog and Shoe when clicked. Test 1: https://prlbr.de/2015/03/html-map.html The first test uses just the classic map and area elements associated with an img. It works in all browsers in big windows, but when the window is resized to be small, it works in no browser as required, because the coordinates in the map's area elements don't scale with the image. This test illustrates the problem that needs to be solved. Test 2: https://prlbr.de/2015/03/html-map-with-javascript.html This test uses the HTML code from the first test plus JavaScript code, which manipulates the coordinates in the map's areas after the page has loaded and whenever the window is resized. This works in all browsers as expected, if JavaScript is enabled, and demonstrates what needs to be achieved. However, this does not work in any browser with JavaScript disabled. This is not satisfactory. I'm not aware of a use case where you don't want an image map associated with an image to be resized whenever the image is resized. So resizing of image maps in accordance with their associated image should really be possible without always adding a JavaScript program. Test 3:
Re: [whatwg] Responsive image maps
I've done a few tests and provide links to them below the following discussion. Am .03.2015, 20:30 Uhr, schrieb Tab Atkins Jr. jackalm...@gmail.com: SVG is highly accessible. Yes, SVG a elements are followed just like HTML a elements, and yes, screenreaders do read out desc elements when appropriate. Nice! Am .03.2015, 21:15 Uhr, schrieb Tab Atkins Jr. jackalm...@gmail.com: On Fri, Mar 20, 2015 at 1:00 PM, Andrea Rendine master.skywalker...@gmail.com wrote: About SVG, I made a couple of tests and they are far from being comprehensive, but this is the fact. SVG image maps need to define 2 elements for each area, i.e. the element itself and its associated hyperlink. That's really not much: svg width=... height=... image src=foo ... / a href=target1polygon points=... //a a href=target2rect ... //a ... /svg The markup complexity seems to be about the same as using img/map/area, especially if you accompany it with prose like the example in https://html.spec.whatwg.org/multipage/embedded-content.html#the-map-element shows. While inline SVGs are somewhat more verbose and complex, I'd say it's justifiable. They also bring advantages like being able to link multiple disconnected areas to a single resource with a single hyperlink. svg elements can be resized by the CSS 'width' and 'height' properties just fine. Yes, though my third test showed an inconsistency that might need to be addressed. .: Tests :. I've done tests with Internet Explorer 9 (IE9), Opera 27 (Opera) on Windows Vista and Firefox 36 (FF), Google Chrome 41 (Chrome), Safari 8 (Safari) on Mac OS 10.10. All test pages show a photograph of a dog and a few items lying on the floor. The goal is to display the photo with 800px × 600px in windows that are larger and have the photo resize automatically in smaller windows, so that there's no horizontal scrolling necessary. The dog and all the shoes in the photo are active areas: they are supposed to show tooltips when hovered and lead to the Wikipedia articles Dog and Shoe when clicked. Test 1: https://prlbr.de/2015/03/html-map.html The first test uses just the classic map and area elements associated with an img. It works in all browsers in big windows, but when the window is resized to be small, it works in no browser as required, because the coordinates in the map's area elements don't scale with the image. This test illustrates the problem that needs to be solved. Test 2: https://prlbr.de/2015/03/html-map-with-javascript.html This test uses the HTML code from the first test plus JavaScript code, which manipulates the coordinates in the map's areas after the page has loaded and whenever the window is resized. This works in all browsers as expected, if JavaScript is enabled, and demonstrates what needs to be achieved. However, this does not work in any browser with JavaScript disabled. This is not satisfactory. I'm not aware of a use case where you don't want an image map associated with an image to be resized whenever the image is resized. So resizing of image maps in accordance with their associated image should really be possible without always adding a JavaScript program. Test 3: https://prlbr.de/2015/03/inline-svg.html This test uses an inline SVG image with width='800px' and height='600px' attributes specified. It's resized via CSS max-width:100%; height:auto !important. This works in FF as required. Opera, Chrome and Safari do something unexpected though: they resize the content of the SVG as expected, but the outer height of the SVG doesn't scale and empty white space is added above and below the photo. Is this a bug in these browsers? Is there something ambiguous in the specs that causes inconsistent behavior? IE9 doesn't get the size of SVG correct at all, unfortunately I can't test it in a newer IE, as IE9 is the last one available for Vista. Test 4: https://prlbr.de/2015/03/inline-svg-without-height.html Test 5: https://prlbr.de/2015/03/inline-svg-without-size.html Test 4 is almost identical to test 3, but I haven't specified a height on the the SVG element this time. Test 5 has neither height nor width specified for the SVG and always gets its size by fitting in the surrounding figure element. Both tests work as expected in FF, Opera, Safari and Chrome. IE9 doesn't get the size right. Test 6: https://prlbr.de/2015/03/html-img-with-svg.html Here I've referenced the SVG (as defined in test 5) with an img element instead of including it inline. This doesn't work in any browser. Except for IE9 the browsers don't even show the included photograph. IE9 shows the photograph, but neither links nor tooltips work. Finally, https://prlbr.de/2015/03/svg-without-size.svg is just the SVG file that I had referenced in test 6. Its behavior is nice and consistent in all browsers including IE9, but not a solution to the problem (unless we drop HTML completely in favor of
Re: [whatwg] Responsive image maps
SVG can be resized. Everything inside it cannot, as far as it is not defined by relative units. And percentage is not limited to ingegers, of course, but it requires a value conversion. And I'm not sure it works with polygons. 2015-03-20 21:15 GMT+01:00 Tab Atkins Jr. jackalm...@gmail.com: On Fri, Mar 20, 2015 at 1:00 PM, Andrea Rendine master.skywalker...@gmail.com wrote: About SVG, I made a couple of tests and they are far from being comprehensive, but this is the fact. SVG image maps need to define 2 elements for each area, i.e. the element itself and its associated hyperlink. That's really not much: svg width=... height=... image src=foo ... / a href=target1polygon points=... //a a href=target2rect ... //a ... /svg The markup complexity seems to be about the same as using img/map/area, especially if you accompany it with prose like the example in https://html.spec.whatwg.org/multipage/embedded-content.html#the-map-element shows. And while SVG graphics offers a wider range of instruments, such a complexity is not always of much use. As such it could be useless to vectorially define parts of the image when the purpose is just to apply a series of shaped links on a preexisting layer-0 image, as it could happen with geographical maps, non-vectorial logos/charts, pre-elaborated graphics. What is important, instead, is that inline SVG images cannot be resized with CSS. And as such they aren't responsive, exactly as image maps. svg elements can be resized by the CSS 'width' and 'height' properties just fine. The only case where CSS resize applies to SVG graphics is when they're used as source for img tag (apart from IE). And in that case hyperlinks are disabled. What we are left with is relative measurement, expressed in percentage for example, but IMHO this is not optimal. On one hand, measuring on base 100 decreases precision, Percentages are not base 100. They're full decimal numbers. You're not limited to integer percentages. ~TJ
Re: [whatwg] Responsive image maps
On Fri, Mar 20, 2015 at 1:30 PM, Andrea Rendine master.skywalker...@gmail.com wrote: SVG can be resized. Everything inside it cannot, as far as it is not defined by relative units. If you use percentage coordinates, or use px coordinates plus a viewBox attribute on the svg, the stuff inside resizes along with the svg container just fine. And percentage is not limited to ingegers, of course, but it requires a value conversion. That math is done to sub-pixel accuracy. It's not anything you need to worry about. And I'm not sure it works with polygons. Polygons implicitly use the px unit (the no unit unit), so you just need to put a viewBox on the SVG to make them resize with the svg root. ~TJ
Re: [whatwg] Responsive image maps
On Fri, Mar 20, 2015 at 12:22 PM, Martin Janecke whatwg@prlbr.com wrote: However, since image maps have been an integral part of HTML since version 3.2 and not been deprecated in favor of a better alternative yet, it might still be a straightforward solution to enhance them. Responsive image maps would be backwards compatible to all non-graphical clients that support at least HTML 3.2 such as Lynx, various bots and presumably most screen readers. Accessibility is already solved for image maps. What are the accessibility implications of using SVGs? In an image map, an area element used as a link must have an @alt attribute providing a link text. It seems that an SVG could use the desc element for that purpose, but it isn't mandatory. Is it understood as link text by screen readers? In case it isn't: do screen reader vendors plan to parse SVGs and make (links in) them accessible in the future? What about search engines? Do/will they handle hyperlinks in SVGs like a and area hyperlinks in HTML? SVG is highly accessible. Yes, SVG a elements are followed just like HTML a elements, and yes, screenreaders do read out desc elements when appropriate. ~TJ
Re: [whatwg] Responsive image maps
On Fri, Mar 20, 2015 at 1:00 PM, Andrea Rendine master.skywalker...@gmail.com wrote: About SVG, I made a couple of tests and they are far from being comprehensive, but this is the fact. SVG image maps need to define 2 elements for each area, i.e. the element itself and its associated hyperlink. That's really not much: svg width=... height=... image src=foo ... / a href=target1polygon points=... //a a href=target2rect ... //a ... /svg The markup complexity seems to be about the same as using img/map/area, especially if you accompany it with prose like the example in https://html.spec.whatwg.org/multipage/embedded-content.html#the-map-element shows. And while SVG graphics offers a wider range of instruments, such a complexity is not always of much use. As such it could be useless to vectorially define parts of the image when the purpose is just to apply a series of shaped links on a preexisting layer-0 image, as it could happen with geographical maps, non-vectorial logos/charts, pre-elaborated graphics. What is important, instead, is that inline SVG images cannot be resized with CSS. And as such they aren't responsive, exactly as image maps. svg elements can be resized by the CSS 'width' and 'height' properties just fine. The only case where CSS resize applies to SVG graphics is when they're used as source for img tag (apart from IE). And in that case hyperlinks are disabled. What we are left with is relative measurement, expressed in percentage for example, but IMHO this is not optimal. On one hand, measuring on base 100 decreases precision, Percentages are not base 100. They're full decimal numbers. You're not limited to integer percentages. ~TJ
Re: [whatwg] Responsive image maps
Am .03.2015, 13:10 Uhr, schrieb Simon Pieters sim...@opera.com: Please leave out syntax proposals for now. What I think is needed first to drive this forward is: * Use cases. Why do you need this? In general it's needed to allow geometric areas on an image to be associated with hyperlinks – that's what https://html.spec.whatwg.org/multipage/embedded-content.html#image-map says – and to associate areas on an image with tooltips. I've used this to name objects in a drawing (think of helping children or foreigners learn words for things displayed in an image). I've also packed small versions of photographs with different aspect ratios nicely aligned in a single preview image file and used an image map to link those previews with bigger sized photographs (https://prlbr.de/2014/wanderung-wanzer-wittenberge/). I've seen Wikipedia link objects in photographs and paintings (star constellations, people) with active image areas. It's also used for site navigation with fancy design. Those are use cases for image maps. Having them work on different screen sizes, e.g. on smartphones and desktop screens, is the main use case for making them responsive. * More examples of pages that work around the lack of this feature. Here's a Wordpress plugin actively used on 7000+ sites: https://wordpress.org/plugins/responsive-image-maps/ Recently I've modified my personal website to be mobile-friendly – except for all the pages that use image maps with differently shaped active areas, because I didn't have a nice solution for these. That's not an example for a work-around of course, but an example for demand for such a feature. Here's a bunch of stackoverflow questions showing more demand: http://stackoverflow.com/questions/1563299/recalculate-image-map-after-window-resize http://stackoverflow.com/questions/7844399/responsive-image-map http://stackoverflow.com/questions/7943003/dynamically-resizing-image-maps http://stackoverflow.com/questions/12214373/image-mapping-responsive-design http://stackoverflow.com/questions/13321067/dynamically-resizing-image-maps-and-images http://stackoverflow.com/questions/20058971/dynamically-resizing-image-maps-and-images-maphilight-min-js http://stackoverflow.com/questions/23752408/resizing-image-maps-containing-circles http://stackoverflow.com/questions/25806090/how-to-detect-and-change-polygon-shape-co-ordinates-in-image-to-be-responsive http://stackoverflow.com/questions/26298771/how-would-i-create-a-dynamic-hit-zone-that-changes-when-resizing-or-moving-the http://stackoverflow.com/questions/26552283/html-image-map-areas-responsiveness * Why are alternatives like CSS-positioned a links […] not better? Unlike a elements, areas in an image map can be shaped as a circle or as an author-defined polygon. That's essential when describing parts of certain images. * Why are alternatives like […] SVG not better? I didn't know SVG could be used for this. This is new to me, so I'm not sure yet, but it looks quite good. Should the outcome of this discussion be that SVG is good enough to solve all use cases and that image maps are not enhanced, I'd suggest adding a hint to SVGs as a note in the image map section of the HTML spec. However, since image maps have been an integral part of HTML since version 3.2 and not been deprecated in favor of a better alternative yet, it might still be a straightforward solution to enhance them. Responsive image maps would be backwards compatible to all non-graphical clients that support at least HTML 3.2 such as Lynx, various bots and presumably most screen readers. Accessibility is already solved for image maps. What are the accessibility implications of using SVGs? In an image map, an area element used as a link must have an @alt attribute providing a link text. It seems that an SVG could use the desc element for that purpose, but it isn't mandatory. Is it understood as link text by screen readers? In case it isn't: do screen reader vendors plan to parse SVGs and make (links in) them accessible in the future? What about search engines? Do/will they handle hyperlinks in SVGs like a and area hyperlinks in HTML? Martin
Re: [whatwg] Responsive image maps
Why are alternatives like CSS-positioned a links or SVG not better?
The issue with CSS is easy. All that can be achieved through it is
rectangles/squares (and their transformations), circles and some
approximation of ellipses (with border-radius). The third feature allowed
by image maps, polygon-shaped areas, cannot be achieved this way.
About SVG, I made a couple of tests and they are far from being
comprehensive, but this is the fact. SVG image maps need to define 2
elements for each area, i.e. the element itself and its associated
hyperlink. And while SVG graphics offers a wider range of instruments, such
a complexity is not always of much use. As such it could be useless to
vectorially define parts of the image when the purpose is just to apply a
series of shaped links on a preexisting layer-0 image, as it could happen
with geographical maps, non-vectorial logos/charts, pre-elaborated
graphics. What is important, instead, is that inline SVG images cannot be
resized with CSS. And as such they aren't responsive, exactly as image
maps. The only case where CSS resize applies to SVG graphics is when
they're used as source for img tag (apart from IE). And in that case
hyperlinks are disabled.
What we are left with is relative measurement, expressed in percentage for
example, but IMHO this is not optimal. On one hand, measuring on base 100
decreases precision, and on the other hand it means defining an SVG
viewport (and related image) 100% x 100% without benefitting of native size
and, what's important, a native ratio, and include it inside an element
whose size is governed by CSS (again, without a native size ratio to rely
on) (didn't test with em units, but the fact is, a simple element{width}
CSS rule wouldn't work). Of course it could be still be of use, but it's
too much of a complexity to force authors on, in easy cases.
Finally, IDK if it can be of any use, but image maps can be defined in
another part of the page itself, so as to provide a list of links added to
the image itself (in some projects it could be useful to leave the user a
choice over favourite interface). Of course this could be done repeating
the links, but it can be avoided.
As a side note, I agree with Martin Janecke. Image maps are still of use
and never gone deprecated. I guess it'd be better to have 2 features which
achieve the same objective in a different way, rather than to force authors
to use SVG just because the other idea hasn't been improved.
2015-03-20 20:30 GMT+01:00 Tab Atkins Jr. jackalm...@gmail.com:
On Fri, Mar 20, 2015 at 12:22 PM, Martin Janecke whatwg@prlbr.com
wrote:
However, since image maps have been an integral part of HTML since
version
3.2 and not been deprecated in favor of a better alternative yet, it
might
still be a straightforward solution to enhance them. Responsive image
maps
would be backwards compatible to all non-graphical clients that support
at
least HTML 3.2 such as Lynx, various bots and presumably most screen
readers. Accessibility is already solved for image maps.
What are the accessibility implications of using SVGs? In an image map,
an
area element used as a link must have an @alt attribute providing a
link
text. It seems that an SVG could use the desc element for that purpose,
but it isn't mandatory. Is it understood as link text by screen readers?
In
case it isn't: do screen reader vendors plan to parse SVGs and make
(links
in) them accessible in the future? What about search engines? Do/will
they
handle hyperlinks in SVGs like a and area hyperlinks in HTML?
SVG is highly accessible. Yes, SVG a elements are followed just
like HTML a elements, and yes, screenreaders do read out desc
elements when appropriate.
~TJ
Re: [whatwg] Responsive image maps
On Wed, 18 Mar 2015 17:22:47 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: ... And as an evidence that someone needs this feature, I could cite several resizing scripts, both standalone https://github.com/davidjbradshaw/image-map-resizer http://stackoverflow.com/a/14576104 and jQuery-based https://github.com/stowball/jQuery-rwdImageMaps Thanks. I've filed https://github.com/ResponsiveImagesCG/picture-element/issues/265 to track this. Please leave out syntax proposals for now. What I think is needed first to drive this forward is: * Use cases. Why do you need this? * More examples of pages that work around the lack of this feature. * Why are alternatives like CSS-positioned a links or SVG not better? * Is there implementation interest among browser vendors? -- Simon Pieters Opera Software
Re: [whatwg] Responsive image maps
That's exactly what I had in mind. I worked for a similar solution (now sadly aborted). It implemented a world map with selectable countries instead of free text fields / dropdown list. I had to use Flash because image maps cannot be resized. I like the idea of using both width and height for consistency, but I am worried about what could happen when either attribute is specified. Of course it would be equally needed to state what is the meaning of a sizes attribute without separator (it could mean that the base map is to be intended as a square, maybe). I took the idea of x meaning times from the current spec about @srcset, where #x refers to CSS pixel density. And as an evidence that someone needs this feature, I could cite several resizing scripts, both standalone https://github.com/davidjbradshaw/image-map-resizer http://stackoverflow.com/a/14576104 and jQuery-based https://github.com/stowball/jQuery-rwdImageMaps 2015-03-18 16:50 GMT+01:00 Martin Janecke whatwg@prlbr.com: Am .03.2015, 12:38 Uhr, schrieb Andrea Rendine master.skywalker...@gmail.com: […] why can't map area coordinates be responsive? I know that percentages simply don't work as UAs either interpret them as pixel, or they aren't interpreted at all. But what about rescaling? I'd like to interpret this question as a request and support it. Imagine something like this (it's a simple example with also an idea for legacy compatibility): map id=mapname name=mapname sizes=400x300 area type=circle coords=50,60,40 / area type=rect coords=0,200,400,300 / /map The @sizes attribute indicates the base dimensions for map rescaling. Lacking it, the map is not resized (so to preserve legacy maps. Polyfill resizing scripts could detect UAs which implement it and let them do it automatically). When the map is applied to an image, 2 values horizontal_ratio (CSS-img-width / map-width) and vertical_ratio (CSS-img-height / map-height) are calculated (I guess they should be 2 because CSS can be improperly used to stretch the image). Then coordinates can then be adjusted according to proper (hor/ver) ratio. This sounds like an easy solution. I'd just suggest to consider whether the @sizes attribute could be expressed differently, i.e. without a new syntax like the x for times. For example, the img element uses two attributes @width and @height to express something similar. Following that example might lead to a more consistent result. I know that a major objection could be that map elements have been out of favor even before responsive design became a focus, but I think it depends on the lack of any relationshipt between maps and rendering layer. Image maps are still used even in a responsive environment. Here's an example from the wild: https://www.deutscheskonto.org/en/ The image using the map is https://www.deutscheskonto.org/images/en/deutsches-konto-600-en.jpg This example uses JavaScript to make the map responsive, but doesn't work when the client has JavaScript disabled. While JavaScript could be used to solve the use case, making image maps responsive is such an obvious application that it makes sense to standardize it without JavaScript. It seems to be the natural evolution of image maps in a time of vastly varying screen sizes. Non-responsive image maps get less and less useful, actually. Martin
Re: [whatwg] Responsive image maps
Am .03.2015, 12:38 Uhr, schrieb Andrea Rendine master.skywalker...@gmail.com: […] why can't map area coordinates be responsive? I know that percentages simply don't work as UAs either interpret them as pixel, or they aren't interpreted at all. But what about rescaling? I'd like to interpret this question as a request and support it. Imagine something like this (it's a simple example with also an idea for legacy compatibility): map id=mapname name=mapname sizes=400x300 area type=circle coords=50,60,40 / area type=rect coords=0,200,400,300 / /map The @sizes attribute indicates the base dimensions for map rescaling. Lacking it, the map is not resized (so to preserve legacy maps. Polyfill resizing scripts could detect UAs which implement it and let them do it automatically). When the map is applied to an image, 2 values horizontal_ratio (CSS-img-width / map-width) and vertical_ratio (CSS-img-height / map-height) are calculated (I guess they should be 2 because CSS can be improperly used to stretch the image). Then coordinates can then be adjusted according to proper (hor/ver) ratio. This sounds like an easy solution. I'd just suggest to consider whether the @sizes attribute could be expressed differently, i.e. without a new syntax like the x for times. For example, the img element uses two attributes @width and @height to express something similar. Following that example might lead to a more consistent result. I know that a major objection could be that map elements have been out of favor even before responsive design became a focus, but I think it depends on the lack of any relationshipt between maps and rendering layer. Image maps are still used even in a responsive environment. Here's an example from the wild: https://www.deutscheskonto.org/en/ The image using the map is https://www.deutscheskonto.org/images/en/deutsches-konto-600-en.jpg This example uses JavaScript to make the map responsive, but doesn't work when the client has JavaScript disabled. While JavaScript could be used to solve the use case, making image maps responsive is such an obvious application that it makes sense to standardize it without JavaScript. It seems to be the natural evolution of image maps in a time of vastly varying screen sizes. Non-responsive image maps get less and less useful, actually. Martin
