W3C home > Mailing lists > Public > www-svg@w3.org > March 2015

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

From: Doug Schepers <schepers@w3.org>
Date: Thu, 26 Mar 2015 01:46:47 -0400
Message-ID: <55139D47.2050002@w3.org>
To: David Dailey <ddailey@zoominternet.net>, 'www-svg' <www-svg@w3.org>, 'Chris Lilley' <chris@w3.org>
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
Received on Thursday, 26 March 2015 05:46:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:00 UTC