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. <jackalmage@gmail.com>:

> On Fri, Mar 20, 2015 at 12:22 PM, Martin Janecke <whatwg.org@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
>

Received on Friday, 20 March 2015 20:01:20 UTC