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

Since this debate seems to be re-starting again, can we please keep it to
the www-svg list, and not continue to spam the WAI list.  Olaf Hoffman
previously tried to rename & re-focus this thread [1], but it didn't catch.

[1]: https://lists.w3.org/Archives/Public/www-svg/2016Aug/0025.html

If you haven't read that note, please do; it outlines many of the security
concerns.

As I think I've said before on this topic, I would not support changing the
behavior of SVG in image tags.  As it is, most social media platforms and
content management systems do not support SVG in images, in part because of
security concerns, in part because of inconsistent rendering between
browsers, and in part just because of legacy ideas about what an image is.

If we gave SVG in images additional behavior inconsistent with other image
types, such as interaction (even non-scripted) and external resources (such
as web fonts) we would be even less likely to convince the developers of
these platforms that SVG can be safely used like any other image format.

Furthermore, interactive SVG in an img tag could not easily be made
accessible.  The accessible representation of an HTML <img> is supposed to
be fully described by its markup, particularly the alt attribute.  Yes, we
could change how SVG images are exposed, but at the cost of up-ending all
author expectations.  When WebKit started making the full content of
embedded SVG graphics available to screen readers last year (similar to an
embedded SVG object), it actually broke the accessibility of many pages,
because the metadata in the external files was not a proper replacement for
the alt text.

As Tab notes, if you want an interactive, accessible SVG embed in HTML, you
can use the <object>, <iframe>, or <embed> tags.

If you are sharing SVG files in a platform that allows SVG in images but
not embedded objects, you can always suggest that readers use the context
menu to open the image in a new tab, which will open it as a fully
interactive independent document.

This feature, though convenient for our purposes, is actually one of the
remaining security concerns with user-uploaded SVG images.  They are
security restricted while embedded as <img>, but have full scripting access
to the host domain if opened as independent documents.  HTTP content
security directives can be used to safely sandbox the file from the host
server, regardless of how the file is accessed, but they are not supported
in some older browsers still in use.

If you're interested in the existing security concerns with SVG images, and
possible solutions to them, there is a good discussion in the comments to
this recent blog post on SVG in WordPress:
https://bjornjohansen.no/svg-in-wordpress

Again, I think any effort to increase the functionality of SVG in HTML
<img> would have the opposite effect to what is desired.  Instead of
increasing the availability of platforms for sharing interactive SVG, it
would lead to even fewer platforms for sharing any sort of SVG.

Regardless, it isn't really our call.  So long as the HTML spec defines
that <img> embeds a "non-interactive, optionally animated, image resource
that is neither paged nor scripted", that's all it will be.

~Amelia