Re: new feature request

Hi, David–

Thanks for your feature request. I apologize for taking a while to get 
back to you, but I wanted to make sure that my own understanding is 
still in line with the SVG WG consensus.

Your simple request seems to have highlighted some confusion in the 
community about the SVG WG's plans for declarative animation. In order 
to clear up some of this confusion, I have created the first draft of a 
wiki page [1] around the SVG WG's plans for animation, including some 
background and some mythbusting. I spoke with Chris Lilley and with the 
SVG WG, and as best as I can reckon, this wiki page is accurate, but I 
invite others to help complete it or correct mistakes.

As you have already noted in another thread [2], the SVG WG still 
intends to allow declarative element-based animation (very similar to 
SMIL), but using the new Web Animation model rather than the more 
complicated SMIL model.

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

The combination of these two features would result in interactive 
declarative animation in an <img> element.

I agree with you that this would be an improvement to Web functionality. 
In particular, I think allowing interactive animated images via <img> 
would be a compelling advantage to SVG over GIFs and comparable use cases.

Down to the pragmatics:

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-based 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.

I think this is a good start, and would encourage browsers to support it 

However, this does not allow for interactive images, which as you note, 
is another very interesting use case not currently possible on social 
media. I suspect that if this feature were introduced, it would become 
quite popular.

At the same time, we do want to make sure that we don't inadvertently 
introduce security or privacy issues.

So, aspect 2 remains an open issue.

I'll note that in the SVG Integration spec, I didn't seem to make a 
distinction between *loading* external resources (e.g. fonts, 
stylesheets, raster images, fingerprinting vector URLs) and following 
external links. I think actually those are two different cases, and that 
following links could be securely allowed.

I also don't see any distinction between insecure and secure 
interactivity in SVG Integration; I'm not convinced that it is a 
security or privacy risk to allow users to start an animation via a 
click or touch or key entry, if there is no access to external 
resources. (Someone please correct me if I'm wrong.)

I don't think that there should be interactivity when SVG is used as a 
CSS background, but I think SVG in an <img> is a different matter. I 
think I conflated them originally, but now think they should be 
separated out.

So, the SVG Integration spec is where these issues would be defined, and 
I think we could start small, by first tackling aspect 1 and then moving 
on to aspect 2.

I'd like to hear what the browser implementers think about this, and 
what their intentions toward SVG Integration are. Are there ways we 
could change SVG Integration to improve it and to get browsers to 
implement it?



On 3/4/15 5:52 PM, David Dailey wrote:
> When SVG is used as the src of an HTML <img> tag, all event handling is shut
> off. I don't remember if this is where this is specified, but I saw it
> somewhere in one of the many places that one might expect to find such a
> thing being specified.
> Now, it does make sense that one might not want the source of one's image
> tags calling scripts and the like. We expect images to be relatively benign.
> On the other hand, SVG is used a lot as the src of HTML img's. If I had
> access to Google's data I could demonstrate such with charts and figures and
> animations that would light up your occipital lobes and bring water to the
> dessert! One word: Wikipedia.
> Now, one of the things SVG is used for is teaching. It is quite useful for
> that. Not just computer science, and math, but other disciplines as well:
> mechanical engineering, chemistry, physics, even anthropology!
> And for teaching, one of the most important things is interaction.
> Well, one of the cool things about SVG (that sometimes people forget) is
> SMIL. It is, in fact, one of the very coolest parts of SVG. It is a
> declarative technology and as such allows non programmers to do animations.
> That non programmers can create content that is shared over the internet.
> one could call such novelty the fundamental principle of the WWW!
> It turns out that without a lick of script, one can use events to trigger
> animations. One can make interactive animations without script. One can even
> upload and display nonscripted SVG at social media sites (the current
> bastion and breeding ground for the animated GIF). Animated GIFs, if you
> haven't noticed are not very accessible. They are a blobs of bits aggregated
> in the least accessible of ways. They border on bad taste if not outright
> immorality! And they are intrinsically, not interactive!
> Anyhow, if the prohibition on SVG inside the image tag listening to events
> (SMIL events) were lifted then a) education prospers in all those parts of
> the world that education is valued b) accessibility is increased c) uptake
> of W3C standards is promoted d) the world is a better place.
> I will call a,b,c and d the use cases.
> Cheers
> David

Received on Monday, 23 March 2015 22:18:45 UTC