Re: Interactive Declarative Animation in <img> (was: new feature request)

Absent from this discussion is what I suspect is a significant legal reason
for social media sites to disallow SVG for the foreseeable future,
regardless of how well supported it is by browsers. For both legal and
brand reasons companies do not want to be caught showing obscene or illegal
content. Technology has been developed to somewhat address this for images
and video but I doubt the same level of protection exits for vector
content, let alone event driven animated vector content.

Maybe "convert to image and then use image technology" is enough for static
drawings, but then you've converted to image, so why not display that?
Event driven animated content seems potentially more dangerous, certainly
to a lawyer.

Stephen.

On Thu, Mar 26, 2015 at 1:46 AM, Doug Schepers <schepers@w3.org> wrote:

> Hi, David–
>
> On 3/25/15 9:39 PM, David Dailey wrote:
>
>> On  Monday, March 23, 2015 6:19 PM, Doug Schepers wrote:
>>>
>> ...
>>
>>> Now, as to your specific feature request, there are actually two
>>> aspects: 1) allow declarative animation in SVGs referenced from an
>>> <img> element 2) allow interactivity in SVGs referenced from an >>
>>> <img> element
>>>
>> ...
>
>> Aspect 1, declarative animation in <img>, is already defined in
>>> the SVG Integration spec, as the "secure animated mode" [3]. I
>>> defined it that way over 5 years ago. It allows timeline-base
>>> animations to be executed. I'm not sure why browsers don't already
>>> support that. One way to help that along would be to create a few
>>> tests for our test suite, which browsers could use to check their
>>> implementations.
>>>
>>
> Note here that Daniel Holbert corrected me on this, and set the record
> straight [1]. Timeline-based declarative animation (using SMIL syntax)
> does work in all modern browsers except those that don't support
> SVG-SMIL animation (i.e. IE). He even provided a working example [2]
>
> [1] https://lists.w3.org/Archives/Public/www-svg/2015Mar/0109.html
> [2] http://blog.dholbert.org/2010/10/svg-as-image.html
>
>
>  However, this does not allow for interactive images, which as you
>>> note, is another very interesting use case not currently possible
>>> on social media.
>>>
>> ...
>
>> So, aspect 2 remains an open issue.
>>>
>>
> Since timeline-based declarative animation is specified and does work in
> browsers, let's concentrate on your other issue: interaction-based
> declarative animation (and interaction in general) in <img>.
>
> FWIW, it wasn't clear that this was what you were asking about. I think
> it's useful to make a strict separation between timeline-based declarative
> animation and interactive SVG.
>
>
>  Thanks for taking the time to write back about this. I see, in the
>> later after-ripples of this discussion, several other issues that I
>> hope to respond to one day, but most importantly, for now, I wish to
>> clarify the status of how things are at the present based on recent
>> experimentation and conversations.
>>
>> Yes, as several people pointed out to me, SVG works inside <object>,
>> <iframe>, <frame>, <embed> as well as inline embedded in either HTML4
>> or HTML5. There is a long history associated with cross-browser
>> inconsistencies, in these matters, and I can provide lots of
>> historical details if it is really of interest.
>>
>> But it is within <img> that I was concerned at present. The
>> discussion  arose because at Ello, the only social network
>>  I know of that supports the  display of SVG (without converting
>> to bitmaps):
>>
>> a) SVG displays,
>>
> > b) SVG animation displays and runs (both <set> and
>
>> <animate>),
>>
> > but
> > not c) SVG script does not activate or run,
> > and
>
>> not d) SVG SMIL-events do not run.
>>
>
> To be clear, it's not about "SMIL-events", it's any user-initiated
> interactivity, including the navigation of links, hover effects, etc.,
> which also includes events that trigger animations.
>
> I think these should be allowed for SVGs in <img>, but we have to figure
> out what that would mean.
>
>
>  One of the other SVG authors at Ello went looking a couple of months
>> ago for an explanation for c) and cited the well-known web page
>> written by one shepazu [1]. I smiled and thought, I know that guy!
>>
>
> A much better reference would be the SVG Integration spec, which is based
> on that earlier document, but more complete and authoritative.
>
>
>  Here's the current status of other social/intellectual media services
>> that I've looked into
>>
>
> (FWIW, I find your notation here decipherable but not optimal; it would
> have been much more clear simply to say that Ello supports SVG display, but
> Wikipedia, Facebook, Twitter, Google Plus, and Pinterest don't.)
>
>  Wikipedia  (a, notb, notc, notd)
>>
>
> This is only partly true, and somewhat misleading.
>
> Wikipedia does allow upload of SVGs, and rendering them as standalone
> files. But they do not allow rendering of them inside of articles, even in
> <img>s. They convert them to PNGs for this purpose.
>
> At SVG Open a few years ago that they said that this was both a security
> and bandwidth constraint (because many of their SVGs are extremely bloated
> with namespace cruft from Inkscape, Illustrator, and the like); they
> probably also didn't want to deal with browser differences at that time,
> but a lot has changed there.
>
> You can see this on the Wikipedia article for SVG (view the source or use
> "Inspect Element"):
>  https://en.wikipedia.org/wiki/Scalable_Vector_Graphics#Example
>
>
> So, in your notation, it should be:
> Wikipedia  (nota, notb, notc, notd)
>
>  Facebook (nota, notb, notc, notd)
>> Twitter (nota, notb, notc, notd)
>>
> > Google Plus (nota, notb, notc, notd)
>
>>   (we fussed to our contacts there  for a
>>   few years but haven't fussed for a few years since)
>>
> > Pinterest (nota, notb, notc, notd)
> > Ello (a, b, notc, notd)
>
> Other interesting sites to include would be DeviantArt, Dribbble, and
> other drawing-sharing sites.
>
>
> But none of this is particularly relevant to standards or browsers, or to
> the issue at hand. This is simply the policy of various sites regarding
> whether they allow the upload of SVG (Ello, Wikipedia), whether they allow
> SVGs to be referenced in an <img> element (Ello), and whether they allow
> SVGs to be referenced in an nested browsing context (e.g. <iframe>) element
> (none of the sites mentioned).
>
> I'm not trying to be dismissive. I'm trying to lay out the facts clearly,
> and to establish clear causation.
>
> What a website chooses to do as its policy is affected by what browsers
> do; what browsers do is affected by the policy of major sites. But your
> list above seems to imply that each of these sites is choosing the behavior
> of SVG in <img> on their site, and that's not the case; they are simply
> allowing SVG in <img>, and the browser handles everything else.
>
> So, the browsers (all but IE) support declarative animation in <img>; the
> question is, can we make the case for them to also support interaction.
> Daniel Holbert (Mozilla) seemed open to exploring the idea, at least.
>
>
>  Okay, thought I (and the CTO at Ello), it makes sense to use <img> as
>> the HTML object that holds un-moderated user-submitted content at a
>> social network. It also makes sense not to enable untrusted 3rd
>> party  JavaScript to run amidst a social web site.
>>
>> But why, really, can we not have declarative events inside <img> if
>> there is no script running there? And I believe I have a compelling
>> set of reasons for wanting such (aka use cases).
>>
>
> Here are some use cases for interactive, formulated in the way a typical
> W3C WG might frame them:
>
> 1) A site wants to allow an SVG image map with animated hover effects,
> using a single image, in a secure way (e.g. no scripting)
>
> 2) An educational site wants to allow users to activate different parts of
> a physics demo graphic, in a secure way (e.g. no scripting)
>
> 3) A testing site wants to allow users to select different items on the
> same image
>
> 4) A financial site wants to allow users to drill down on different values
> in a data visualization, in a secure way (e.g. no scripting)
>
> 5) An ad agency wants to deliver animated ads, some with interaction such
> as rollovers and simple games to engage readers, over an ad network, with
> minimal file size and no script or video allowed; they also want to allow
> users to turn off the animations with a click
>
>
> These are succinct, distinctive, and illustrate the specific need for
> interactive SVG and declarative animation; off the top of my head, I can't
> think of an elegant way to solve these except with interactive SVGs. This
> would probably be a pretty effective way to state use cases for future
> requests; more effective than longer rhetorical or emotional prose, because
> people can quickly read and evaluate the use case on its merits.
>
> So, we have some use cases. The next step is to demonstrate that there is
> demand for these use cases by real-world sites...
>
>
>  Now, after my post "new feature request" but before the hoopla
>> unfolded here at www-svg surrounding the issue of "is SVG SMIL really
>> going to go the way of dinosaurs?", someone from Google had actually
>> written to me, saying, in essence "this is a good idea" why don't you
>> write to the good folks at Wikipedia?
>>
>> I did. I remembered there was a fellow who presented at The Graphical
>> Web 2009, when Google hosted the conference [2], who was from
>> Wikipedia, so I thought: I will write to him. So I did. He happened
>> to be the CTO there.
>>
>> He seemed quite enthusiastic about the idea of animated and
>> interactive SVG at Wikipedia. So in answer to someone's question:
>>
> > yes, we have interest from folks who would appear to be important
>
>> at two important places: the  only two places that actually allow
>> display of user-uploaded SVG.
>>
>
> Okay, now we're cooking! We have some clear use cases, and we have some
> major sites that have expressed interest (and with the advertising case,
> probably even more).
>
> An individual at Google (we don't know how whether they're empowered to
> make decisions for either the browser or the content teams, but they could
> at least spread the word), and the CTO at Wikipedia, as well as (maybe?)
> the CTO at Ello (which is not major yet, but is pretty well known) all like
> this idea.
>
> It would be even better if these folks would post to the list, or at least
> allow you to forward their emails to the list, but I trust you at your word.
>
> I'll bring this up at the next SVG WG telcon, and see if we get traction.
> I still can't promise that it'll make our priority list, but if there's
> general agreement, I'll change the SVG Integration document to allow this.
>
>
> In the meantime, if someone wanted to help gather (or create) example SVGs
> for each of those use cases (or similar ones), that would be a really
> concrete demonstration that we could use to convince other sites to change
> their policy toward SVG in <img>.
>
>
>  That's the best I can do for now, in terms of reply to the various
>> conversations this topic brought up. It is good to see that the idea
>> has some receptivity, both in the "real world" and at www-svg.
>>
>
> Thanks for doing that, and for bringing this use case up in the first
> place!
>
>
>  In response to Daniel Hobart's concern in which he writes "I'm
>> mildly concerned that this might violate authors' expectations about
>> what user-submitted images are capable of doing.", I appreciate the
>> thoughtful concern, I'm not sure how it might be problematic.
>>
>
> I agree. The keylogging problem doesn't work without external resources or
> script, and in the worst case, we could define a "secure interactive
> animated mode" that allows clicks by not keyboard events (though that would
> miss some use cases, and might have accessibility issues).
>
>
>  The places like  Facebook and Google Plus and Twitter that are still
>> afraid of SVG might as well get the whole nine yards (including
>> non-scripted interactivity) when they finally (we would hope)
>> overcome their apparent fear of things like SVG.
>>
>
> *sigh*
>
> I wouldn't characterize it as "fear", but rather simple expectations of
> return on investment. If we can show them that there is little cost, little
> risk (e.g. security), and some benefit, and that other sites are doing it,
> it's likely to catch on.
>
>
>  Users have seen interactive images (Adobe ImageReady
>> rollovers and the  like for 20+ years) and I have seen
>> people in three different social  environments ask for
>> interactive images on social media. I'm not saying that
>> there  isn't a problem, it's just not in focus for me yet.
>>
>
> I think this is a pretty good defense of the idea of user expectation. I
> suspect that most users who see something animated would not be surprised
> if it were also interactive (if only to turn off the animations).
>
> Regards–
> –Doug
>
>