W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2015

Re: [whatwg] Responsive image maps

From: Martin Janecke <whatwg.org@prlbr.com>
Date: Sun, 22 Mar 2015 15:06:40 +0100
To: "WHATWG List" <whatwg@whatwg.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
Message-ID: <op.xvwj5ee6wnok4b@localhost>
I've done a few tests and provide links to them below the following  

Am .03.2015, 20:30 Uhr, schrieb Tab Atkins Jr. <jackalmage@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.


Am .03.2015, 21:15 Uhr, schrieb Tab Atkins Jr. <jackalmage@gmail.com>:

> On Fri, Mar 20, 2015 at 1:00 PM, Andrea Rendine
> <master.skywalker.88@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=target1><polygon points="..." /></a>
>   <a href=target2><rect ... /></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  

.: 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 <area>s 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 defining the whole webpage in SVG).

.: Conclusion :.

Test 4 and 5 show that inline SVG is a viable solution. I hope the  
inconsistency from test 3 can be solved as well.

.: Final notes :.

I'm fine with inline SVG "image maps" in HTML5.

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"  

The SVG solution discussed above references the image by a different SVG  
mechanism. That particular SVG solution is not an option for use cases  
where the <picture> element's qualities are needed. It might be possible  
to adapt the SVG solution to also work with <picture>, for example by  
placing a transparent inline SVG on top of a HTML <picture>/<img> element,  
possibly adding further complexities. Whether enhancing the native HTML  
image <map>s is a better solution then might need to be discussed. I can't  
provide useful feedback there, as I haven't used <picture> myself.

Received on Monday, 23 March 2015 02:11:30 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:29 UTC