Re: Interactive Images (was: SVG 2 review request)

On Mon, Aug 15, 2016 at 3:16 PM, Doug Schepers <[email protected]> wrote:
> 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.

Note that "link navigation" is also potentially a security-conscious
behavior that sites might want to restrict, or at least would be
surprised if it was suddenly allowed.

<iframe sandbox> gives you guaranteed-safe SVG embedding, *and* lets
you more granularly shut down or enable a few more behaviors from the
defaults.  Using either <img> (for static images) or <iframe sandbox>
(for interactive images/documents) as you feel appropriate should be
all we need.

~TJ