Hi David, On 2015/07/14 5:58, David Dailey wrote:
I'm a bit confused (still). In looking through the document, it looks as though almost everything that looks like "traditional" animation (in terms of the 15 year old thing that people used to call a "W3C Standard" -- I finally understand W3C's use of the word "recommendation") has been replaced by JavaScript calls.
Web Animations consists of two parts: an abstract model for animation and a Javascript API for that model.
The intention is that declarative technologies such as SVG's animation elements and CSS animations/transitions can be built on top of that model so that they don't have to independently define things such as timing functions or, "what happens if I have a negative delay longer than the animation duration with a forwards fill mode and a non-integral repeat count?".
A UA that does not support Javascript could ignore the API part of the specification altogether. On the other hand, for UAs that support script, the API provides a way of testing that the markup correctly maps to the appropriate pieces of the model. It also provides a common interface for querying and manipulating animations regardless of whether they came from CSS animations/transitions or SVG or were generated by the API itself.
Questions: 1. Realistically, how long might we have until everything breaks? (By everything, I only mean the SMIL animated stuff). I think previous versions of the Web Animations document still referenced declarative animation. The current one says: " The animation features in SVG 1.1 are defined in terms of SMIL Animation [SMIL-ANIMATION]. It is intended that by defining SVG’s animation features in terms of the Web Animations model, the dependency between SVG and SMIL Animation can be removed."
Nothing has changed between different versions of the Web Animations document with regards to its relationship to declarative animation. The only difference I can think of is that we have added more API examples since talking about the model in the abstract is quite difficult.
Other than that, Web Animations is not intended to compete with declarative technologies, but support them as Zack's message points out.
On a practical note unrelated to Web Animations, I don't know of any specific intention to remove SMIL support from Firefox, but it will be hard to justify improving it if other UAs drop support for it.
2. Is the thought that all things that were previously declarative will now be done with either script or CSS? I think I'll need to see examples to understand what the putative future of animation is to look like. I recall that CSS has vowed never to do certain things that SVG does, and it shouldn't since it is wrong on 108 distinct levels. But requiring only scripted solutions would be most unfortunate as well!
That does seem to be the current trend. The gap between CSS and SVG is still large, however.
3. In the past we could send messages back and forth between animation (SMIL) and JavaScript to a) trigger, for example, motion along a curve or interpolation between two curves from script and b) call script upon termination of some animation (see for example http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/Polygons/polygons10.svg which solves, in polynomial time, a long-standing problem thought to require N! steps. A small bug in Firefox, leaving chunks of pixels on the screen has been filed) . Will that still be possible?
* Motion along a curve: Yes. With the motion path module[1] it is possible to create a motion-along-a-curve animation either from CSS or using the Web Animations API (or a combination of both; for example, create the animation in CSS, pause it and trigger it later using the Web Animations API).
* Interpolation between two curves: Not yet. There has been some discussion about this as you are no doubt aware.[2] The contention is around whether we should just promote SVG's 'd' attribute from the <path> element to a CSS property as-is, or whether we should do something better and more CSS-like and more suitable for animating instead.
* Call script on termination of some animation: Yes. Web animations provides two means for this: listening to the finished promise of an Animation, or listening to finish/cancel events (not in the most recent WD since I only added it last week). CSS likewise provides animationend/transitionend events.
4. One other question, I guess for the Blinkers among you: should we stop filing bugs in Chrome and Opera until SVG incorporates Web Animations or some other way to do animation? I have a few score of examples that are currently broken in Chrome. No sense reporting bugs if SVG is going away. How about Firefox? I understand that Firefox does not intend to withdraw support for SVG1.1, but if the SVG spec no longer mentions animation, then wouldn't fixing bugs associated with it become less of a priority?
It's still worth filing the bugs if you don't mind. While it's true that paid contributors might have difficulty justifying spending resources on a technology that other UAs are deprecating (when there is plenty of work to be done on other specs with broad support), volunteer contributors or paid contributors in their spare time might be able to pick up some of them.
Best regards, Brian [1] http://dev.w3.org/fxtf/motion-1/ [2] https://lists.w3.org/Archives/Public/www-svg/2015Jun/0000.html
