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.org@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. <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.
>>
>
> Nice!
>
>
> 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
> 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
>

Received on Monday, 23 March 2015 11:51:18 UTC