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=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
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.
Martin
