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