Interactive Images (was: SVG 2 review request)

Hi, Tab, Patrick–

On 8/15/16 5:10 PM, Tab Atkins Jr. wrote:
> On Sat, Aug 13, 2016 at 2:49 AM, Patrick H. Lauke wrote:
>> On 13/08/2016 05:50, Doug Schepers wrote:
>>> I'd like to hear a more concrete explanation of why interactivity
>>> in <img> must be disallowed.
...
>> *IF* you wanted to add something interactive inside an <img>,
>> you'dneed to signal this with at least
>>  the addition of a different role="..."  attribute
>> (and then change user agent behavior, which would assume <img> is
>> non-interactive, so presumably doesn't cater for focusability
>> etc).
>> But this still feels like a conceptual stretch...
>
> Yup! And it's a completely *unnecessary* stretch, because HTML
> *already* has elements that indicate interactive embedding of
> resources: <iframe> and <object>!  There's zero need to fiddle with
> <img>'s semantics.

If you'll read the original thread, you'll see that the issue is more
subtle than that.

Many sites and services only use <img> because it bypasses the security
problems that using <object> or <iframe> would introduce.

In terms of user-expected behavior, most users are familiar with image
maps, where there is interactivity (specifically, link navigation); to
them, it doesn't matter if the link is specified in the HTML file or the
image file, they only know the UI behavior. Similarly, CSS ::hover
effects seem like interactivity on the image to users.

Allowing certain kinds of interactivity in <img>, such as link
navigation or declarative animation (like ::hover) or text selection,
but not script execution, would continue to match user and author
expectations about security and behavior, while also allowing more
interesting options for SVG images.

Regards–
Doug

Received on Monday, 15 August 2016 22:16:58 UTC