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.


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

That's really not much:

<svg width=... height=...>
  <image src=foo ... />
  <a href=target1><polygon points="..." /></a>
  <a href=target2><rect ... /></a>

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>

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 <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" (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. 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.


Reply via email to