W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2013

Re: [web-anim] "Seamless" additive animation

From: Brian Birtles <bbirtles@mozilla.com>
Date: Tue, 11 Jun 2013 15:36:48 +0900
Message-ID: <51B6C580.5090301@mozilla.com>
To: Kevin Doughty <default@kxdx.org>
CC: public-fx@w3.org
Hi Kevin,

(2013/06/11 14:50), Kevin Doughty wrote:
> I am racing to familiarize myself with the Web Animations, SMIL, CSS Animations, and CSS Transitions specifications. I am probably mistaken about the results of what you describe, but this is what I have in mind:
> start keyframe {
>     additive: sum
>     prop: <previous unanimated value> - <current unanimated value>
> }
> end keyframe {
>     additive: sum;
>     prop: 0;
> }

Looks good to me.

> I can't find reference to a to-animation in the Web Animations spec, so I am referring to 3.2.2 at http://www.w3.org/TR/smil-animation/#AnimFuncValues when I say "seamless" animation could be considered an "additive reverse by-animation".

Yes, it's not referred to since it's simply a particular pattern of 
keyframes. Web Animations tries to describe the primitive pieces and 
then other specs can offer shortcuts for common patterns like 

>> It seems like, in effect, this is equivalent to simply using to-animations with a forwards fill and not updating the underlying style. However, I can see it has the advantage of providing better non-animated fallback and of affecting the specified style (which may be useful when style is used to track state).
> If you never update the underlying style, you would never be able to remove a bunch of additive to-animations, would you?

That's right, but these are defined in a way that makes it possible for 
implementations to do this efficiently (provided certain conditions are 
met, they can discard the animations and only store the final fill value).

 > And for layout, a pattern of waiting for animations to end before 
setting the underlying style to match is just plain wrong.

The point of this particular approach is you don't set the underlying 
style. For some use cases that's quite acceptable, for some it's not and 
I agree that for the use cases you've presented it's not a good fit.

Best regards,

Received on Tuesday, 11 June 2013 06:37:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:46 UTC