Re: new feature request

Hey, Daniel–

On 3/23/15 9:17 PM, Daniel Holbert wrote:
> On 03/23/2015 03:18 PM, Doug Schepers wrote:
>> 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.
>
> All browsers that I'm aware of, except IE, do already support this. (And
> IE only doesn't support it because they don't implement SMIL.)
>
> See my super-realistic animated swimming fish graphic here for a demo:
>    http://blog.dholbert.org/2010/10/svg-as-image.html
> It uses <img> with a SMIL-animated SVG source.

Mea culpa. I should have checked… it would only have taken me a few 
minutes, but I assumed that David and others were saying it didn't work.

("The Holbert Report"… nice. But you might need to change it to "The 
Late Show with Daniel Holbert", which is not as catchy.)


>> 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 agree, as I noted elsewhere in this thread (
> https://lists.w3.org/Archives/Public/www-svg/2015Mar/0073.html ).  I
> don't think there's any security issue with allowing interactivity in
> images. (But I'd love to be proven wrong!)

Yes, I saw that, and meant to reference your email. (I guess I got lazy 
after writing that wiki page… which I've now had to revise.) I apologize 
for neglecting to give due credit.

I agree with your analysis, both the good and less-good aspects of 
allowing interactive animated images.


>> 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.
>
> Why? Authors choose to use CSS backgrounds over <img> tags sometimes;
> I'm not sure why we should shoehorn them into using <img> if they want
> to benefit from this.

My reasoning, which may be wrong, is that backgrounds shouldn't be 
interactive, lest they cause confusing and conflicting behavior with the 
page content. I'm also unclear about the state retention in CSS 
background images; for some reason, it feels like in the <img> element, 
SVG content would be saved in a sort of shadow Dom, while I'd expect it 
to be discarded for a CSS background image. So, it's not clear what the 
event model, etc., would be, if that's the case.

Again, I might be wrongheaded here, but that's my gut reaction.


> (I do think it makes sense to exclude e.g. <canvas> (w/ drawImage) and
> <feImage>. Those use-cases are fundamentally different, in that they
> read a static snapshot of image pixels and manipulate it, and the image
> is abstracted away further -- so those probably can't meaningfully be
> interactive.)

That's how I'd expect CSS backgrounds to work, too… but maybe that's 
wrong, and it would be useful to have responsive/media-query SVGs doing 
cool things as responsive backgrounds.

(That doesn't necessarily mean that they would be interactive, just that 
they would be retained-mode, but it's something to think about which 
needs definition.)


>> 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?
>
> I'm not clear on what you're asking here -- maybe the question is partly
> answered by my first point above? (the fact that browsers (the ones that
> support SMIL) *do already* implement "secure animated mode".

Thanks for the correction. That does answer the first question, about 
supporting declarative animation in <img> SVGs.

(That said, we still need to confirm that we have adequate tests for 
this in our test suite.)


The second question is still open: what about interactive SVGs in <img>?


> At a high level, I'm mildly in favor of supporting interactive SVG
> images, but I'm not sure where that fits in, priority-wise, and I'm
> mildly concerned that this might violate authors' expectations about
> what user-submitted images are capable of doing.

That's a reasonable concern, though I'm more optimistic about 
author/site expectations there, especially if we make it clear that 
there are no known security or privacy issues.

As far as priorities… I think the first priority should be finishing the 
Web Animation spec and Animation Element spec, and trying to get 
IE/Spartan to support it. Then we can see about extended capabilities.

But I'd be pleased if some browser took the lead and started supporting 
interactivity in SVG <img>s, so we could see what authors do with it!


Thanks for your corrections, thoughts, and feedback, this was most helpful!

Regards–
–Doug

Received on Tuesday, 24 March 2015 04:04:01 UTC