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

On Jun 10, 2013, at 9:30 PM, Brian Birtles <bbirtles@mozilla.com> wrote:
> If I've understood the use case correctly, the arrangement is something like the following:
> 
>  start keyframe {
>    additive: replace;
>    prop: <previous value>;
>  }
>  end keyframe {
>    additive: sum;
>    prop: 0;
>  }
> 
> Independent animations are then combined using a stack where the additive operators are used to determine how they combine.

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;
}

Looking at https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html#calculating-the-result-of-an-animation-stack I think my having used the term "underlying value" was confusing. I am describing a usage pattern intended for layout, implicit transitions which are animations added when a property is changed. I hope using previous and current "unanimated" value is clearer. In Core Animation terms it is called the model value as opposed to the presentation value.

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".

Most patterns I see have animations that completely override this unanimated value. The actual property value has absolutely nothing to do with what is shown when animated. The pattern I describe has this value instantly change. At the same time adding an additive animation with the correct delta has the effect of instantly moving the property back to where it came from, and then animates it to a zero delta. When the animation is done, the animation can be removed as it has no further effect, the animated state matches the unanimated state.

> 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? This could be bad if you were animating on user initiated resize something like an isotope.js grid or like I do with the glyphs of NSTextView. And for layout, a pattern of waiting for animations to end before setting the underlying style to match is just plain wrong.

Regardless of how many additive animations are running, as long as you continue to set the model value while using this negative by-value delta, you will get smooth and seamless curves.

Received on Tuesday, 11 June 2013 14:30:47 UTC