Re: [web-animations] Request to publish another WD of Web Animations

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

Received on Tuesday, 14 July 2015 00:55:17 UTC