Re: [whatwg] Responsive image maps

> The active area in the svg is whatever the active graphical shape is, I
don't quite understand what you mean that it's unclear
The main difference between native SVG implementation and "native" <area>
implementation (map/area scenario lets you small room for maneuvering, so
it's native anyway) is that image maps, using tab navigation, don't expose
active area. On Chrome there's a large rectangle highlighting the area (or
areas in case of link spanning over multiple items), on every other
platform there's no native highlighting at all. It's true, you can do it
with CSS, but in image maps it's already implemented. As said, it's only a
matter of implementation though. Going further, it will be redefined.
The fact is always the same: as it's all a matter of implementation, I
strongly believe that a mean of natively resize maps should be implemented
anyway. You are right, SVG is more flexible with CSS and JS support, but
flexibility comes with a cost: those rules have to be defined.

> Tabbing through an svg probably works best if the svg is inline in the
html document
For the purpose of this thread, embedded SVG simply wouldn't make any
sense. We are talking about links connected with the subject of the
document, it goes over the purpose of the image itself (see my note about
relative paths above, too).

However, there's another point, which IDK if can matter. Maps can be
included at any point of the document. With some CSS they can be used as
out-of-context item lists, and they can also be reused for different maps
inside an image, while SVG have to be repeated.

2015-03-31 16:02 GMT+02:00 Erik Dahlström <ed@opera.com>:

> The active area in the svg is whatever the active graphical shape is, I
> don't quite understand what you mean that it's unclear. The active shape
> can also be styled with css based on :hover or :active rules, for example
> to add an outline or to do some sort of visual highlighting.
>
> For controlling the tab order there's the tabindex attribute (added in
> svg2), which has the same behavior as in html. Tabbing through an svg
> probably works best if the svg is inline in the html document. Support for
> tabindex in svg is implemented in Blink and WebKit already.
>
>
>
> On Wed, 25 Mar 2015 21:24:04 +0100, Andrea Rendine <
> master.skywalker.88@gmail.com> wrote:
>
>  One of the 2 objections, I'd say. But the second is probably a matter of
>> implementation.
>> SVG makes it unclear what's the actual active area when navigating through
>> tab key.
>>
>> 2015-03-25 19:32 GMT+01:00 Tab Atkins Jr. <jackalmage@gmail.com>:
>>
>>  On Wed, Mar 25, 2015 at 10:03 AM, Andrea Rendine
>>> <master.skywalker.88@gmail.com> wrote:
>>> >> Instead, we start by figuring out what problems need solving.
>>> > Which is what has been done for this subject, I guess.
>>> > PROBLEM: image maps, intended as "shaped link areas related to specific
>>> > regions of an image" are a fairly requested feature. Unfortunately, as
>>> > current solutions are not responsive and they can't fit to how images
>>> are
>>> > defined in a modern scenario, with scalable size and art direction,
>>> authors
>>> > have looked for workarounds, script-enhanced or non-native (Flash maps)
>>> > solutions.
>>> > POSSIBLE SOLUTIONS: 1. link boxes and CSS, 2. SVG, 3. <map>, where
>>> >  1. CSS has a poor range of shapes
>>> >  2. See above for SVG
>>> >  3. <area> coordinates are absolutely defined.
>>> > PROPOSAL: As SVG map is not viable at all in complex <picture>
>>> scenarios,
>>> > and not easily viable in simple contexts, authors could benefit from
>>> <map>
>>> > versatility. So a viable solution *could* be to improve a feature in
>>> order
>>> > to make it responsive.
>>> > The "Map element improvement consortium" is not an organisation I want
>>> to
>>> > mindlessly support (basically because it doesn't exists). And
>>> unfortunately
>>> > I tend to be verbose when I start writing. So in my last message I
>>> tried
>>> to
>>> > make it shorter and I chose terms incorrectly.
>>>
>>> Note that we *should* just be able to use <picture> in SVG, which
>>> helps that solution.  This is generally useful (we want responsive
>>> images inside of SVG, too), and afaict, removes the only objection to
>>> SVG.
>>>
>>> ~TJ
>>>
>>>
>
> --
> Erik Dahlstrom, Web Technology Developer, Opera Software
> Co-Chair, W3C SVG Working Group
>

Received on Tuesday, 31 March 2015 14:17:58 UTC