RE: new feature request

On  Monday, March 23, 2015 6:19 PM
Doug Schepers wrote:

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

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?


[1] https://www.w3.org/wiki/SVG/Animation
[2] https://lists.w3.org/Archives/Public/www-svg/2015Mar/0090.html
[3] https://svgwg.org/specs/integration/#secure-animated-mode

Regards-
-Doug

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.
--------------
Hi Doug,

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.

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!

Here's the current status of other social/intellectual media services that
I've looked into

Wikipedia  (a, 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)

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

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.

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. 

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


Regards
David

[1] http://www.schepers.cc/svg/blendups/embedding.html 

[2] https://www.graphicalweb.org/2015/ Pittsburgh Sept. 23-26 2015.

Received on Thursday, 26 March 2015 01:40:44 UTC