Add a way to specify a ping-pong animation in SVG

[Emasoft]

There is no direct way to specify a ping-pong animation in SVG, that is to tell an animation to go back in time when it reaches it's end.

The current work-around is to copy the original animation (call it e.g. "mymotion") and swap the from and to values in the copy. Then we need to specify begin="mymotion.end" to tell the backward animation to start right at the end of the forward animation. But this work-around increases the size of the SVG up to 2X, and it is clearly inefficient for big svg files.

In SVG 2 there should be a parameter to specify a ping-pong animation in SVG. Many looping animations used for animated stickers in apps like "Viber" would benefit from this, reducing the size of their SVG stickers by an half.

This would also be useful for "toggle" animations in SVG animated icons or buttons. The first touch would animate forward (i.e. activate animation), and the second touch would animate backward (i.e. deactivate animation).

Same for on-hover animated icons (mouse enter activate animation, and mouse exit deactivate the same playing it backward).

Those 3 are very common usage scenarios for SVG, and they would all benefit from ping-pong animations.

A simple animatable parameter like direction="forward | backward" would be enough. When changed (i.e. by a click event), the animation does not reset, it just continues the playback backward from the frame/position is currently on back to the original/from state (and vice versa).

[tabatkins]

Already handled by CSS Animations / Web Animations, which now apply to all of SVG.

[Emasoft]

According to the GreenSock guys, there is no way to reproduce this demo with only CSS:

http://codepen.io/GreenSock/pen/AwCKp

You need javascript. On iOS mobile you cannot use javascript or any other VM. Is the new CSS Animations/Web Animations protocol included in SVG 2 able to reproduce the above code example without using javascript? If not, then the issue is not handled yet.

[tabatkins]

Assuming that's just a text-path animation, that will be doable with CSS as soon as implementations get updated to make that a CSS property. In general, running animations forwards or backwards is controlled by animation-direction.

[Emasoft]

It is not just about text. The Greensock guys wrote the following in the accompaining article: "(with CSS) you cannot seek to a particular spot in the animation, nor can you smoothly reverse part-way through or alter the time scale or add callbacks at certain spots or bind them to a set of playback events. (..) You are not able to animate from variable starting values to variable ending ones (based on where the user clicks), or change things on-the-fly." Is this true? Or can you show me a way to replace the javascript with CSS in that demo?

[tabatkins]

You can seek to a particular part in pure CSS by setting a negative animation-delay appropriately.

Everything else is stuff that is doable via Web Animations. Doing it in SMIL is either using JS too, or using the tiny amounts of pseudo-scripting that SMIL contains and which we're definitely not planning to put into CSS animations.

[AmeliaBR]

Hi @Emasoft,

If further work on SVG Animation Elements is pursued, yes it makes sense to include an attribute to easily create alternating animations. As @tabatkins notes, alternating animations are a core part of the Web Animations API and are already available in CSS animations. Since the intention was that SVG Animation Elements would become an alternative declarative interface for the Web Animations API, it would make sense to add this convenient feature via a new attribute.

However, as we've mentioned on other issues, there is currently no active work being done on the SVG Animation Elements specification, because of a lack of interest from W3C members who implement SVG user agents. I would encourage you to try to find people and organizations who are interested in XML animation syntax to join together in a Web Incubator Community Group if you would like to help push the specification forward.

Active work is being done to establish the infrastructure so that all non-interactive SMIL animations can be converted to CSS animation syntax. We're not there yet, there are still complexities for some attributes that cannot yet be specified via CSS, but we're working on it. Once animations are converted to CSS, alternating "ping-pong" animations will be easy. Since you're so passionate about SVG animations, I encourage you to explore the potential of the CSS syntax, and offer concrete suggestions for missing features.

Regarding the rest of the discussion: the examples you give of animations which cannot be done with CSS (variable start points and times based on user interaction) also cannot be done with SMIL / SVG Animation Elements. The specific linked CodePen does not even use SVG, it uses CSS transforms of HTML elements. For SMIL animations with basic user interaction (i.e., with event-based start and end times), the alternative is JS and the Web Animations API. SVG-as-image will never support user interactivity, so the lack of script support in images is not relevant.

I'm going to re-open this as a valid feature request for the SVG Animation Elements specification. But again, don't expect any action in the near future.

[Emasoft]

@AmeliaBR Thank you, Amelia. I'll look into the WICG. I'm also working to add a SVG SMIL export option to the OpenToonz project. I'm definitely interested in all non-interactive options of the SVG Animation Elements. But I'm also interested in defining very simple interactive behaviours for web components that can be played without the use of javascript.

For example the "toggle" behaviour of an SVG button with a ping-pong effect when interrupted (i.e. touching start an animation from keyframe A to B, touching again from B to A, but also touching at any intermediate point reverse the playback direction, so you can play the animation back and forth at any time). This is what graphicians and artists need for creating and testing SVG assets. After an artist save and test a button or an icon (for any project, being it web, mobile, desktop, videogame UI, etc.) he just need a basic interactive way to click/touch and see the animation play from one state to another. And he should be able to send the svg file with the button or icon to any other member of the team, confident that he is able to test the button in a browser and see the same behaviour. Sometimes more than 2 states can be required for an icon (i.e. a switch with 4 positions, for example, or a mix of mouse-over states with selected/unselected states). To solve that case, all we need is to extend the SWITCH statement to include the option to check for mouse over or for some current invisible property of the button, a property that can work as a selected/unselected state flag. Integrating such basic options in the SVG standard would make possible to use SVG UI components in the entire work chain: from the design phase in Invision or AdobeXD, to the SVG asset integration in the final native code of the app. And at any time the artist would be able to change or correct something in the SVG animation file, without forcing the other members of the team to change and redo all their work again to update it. That would make SVG a true graphic animation format, independent from the implementation of the viewer like a PNG. Very little is needed to make SVG an asset artists can work with. But we need to do it. Otherwise, SVG would always be bound to the work of programmers, and that would limit its potential as a graphic file format.