- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Tue, 11 Jun 2013 15:36:48 +0900
- 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 'to-animation'. >> 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, Brian
Received on Tuesday, 11 June 2013 06:37:13 UTC