Re: [css3-transitions] "seamless" additive animations

> the properties are *far* too well-established in the wild to permit changes that break backwards compatibility.
Isn't that what the vendor prefixes are for? Oh well...

> it's unclear exactly how that would look, syntax-wise.
It is unclear for me as well, but I hope to influence those able to make this kind of decision.

It seems the choices are either make a single "one key enables all" property, or expose a couple that are required to accomplish the same thing. 

A special mode could be named something like transition-blend, transition-blending, transition-seamless, transition-smooth, or transition-interpolate. It would use the old minus new from value and zero to value. This could be considered a "reverse by" animation, with the intent that you set the new underlying model value then animate back from where it was to zero. The timing function should be a "perfect" cubic bezier with control points .5 0 .5 1, and perhaps not changeable at all.

The alternative is transition-additive, the same timing function for convenience, but also another property to specify the old minus new calculation. This needs to use the previous underlying model value, not start from the presentation value.

The awkward rules from CSS Transitions Section 4 (Automatically reversing interrupted transitions) must not be used with this mode. From this list, the problem was first stated as "the movement back to the original position ends up much slower than the movement away from it, since it uses the full transition-duration for just a partial change in the movement." But I believe there are somewhat similar problems anywhere you interrupt and replace animations, not just the edge case addressed by section 4. The second video at http://kxdx.org/animation-sample-videos/ shows before and after samples of this. The CocoaSlides portion shows undesirable grid layout animation. It looks like Isotope.js avoids this with a simple delay, but that might also be for performance reasons.

The Xcode project "Additive101" from the workspace repo https://github.com/KevinDoughty/AdditiveSamples shows the section 4 issue and why this special mode would not need it. It is the simple push animation of black and white layers from the first video from the previous link. If the additive check box is unchecked and you click "toggle" twice rapidly, the undesirable asymmetric effects are visible. If additive is checked, there is no problem because the first animation does not immediately end. Instead it slows down, stops, then reverses. An A->B->A->B case (clicking "toggle" three times), depending on how fast it is triggered, could barely slow down at all, or slow down and stop but then speed back up towards the destination, or do a S-curve, reversing then reversing again.

> We proposed (years ago now :) to have additive animations via a CSS property.
> animation-additive: additive;

I am afraid to encroach on features dismissed as "easily handled by nesting elements". But I do hope additive will be reconsidered now that the fundamentals have been implemented. I would also very much like additive CSS3 animation. This technique works for keyframe animations, which can be seen in the first video.

If there was a single "one key enables all" property, the additive nature and conversion from absolute to relative calculations could be a private implementation detail, to spare developers from having to put to much thought into it. I haven't tested this yet, but explicit animation of floating point property from 2 to 10 when the underlying value is at 4 (and is not ever changed) could, behind the scenes, produce an additive animation with a from value of (underlying model value + (desired from value - desired to value)) which is -2 and a to value of (desired to value - underlying model value) which is 6. The benefit would be that later, unrelated instant changes to the underlying model value would not break running animations, or at least would produce less visual inconsistencies than if the animation were defined absolutely. I rely on this technique for things like window resize to layout layers instantly, while they still have animations running.

The last thing I want to mention is a technique I used for the NSSplitView animation in the third video, from a Core Animation perspective. From the Mountain Lion AppKit release notes there is a suggestion of using NSAnimationContext's runAnimationGroup: with a completion handler, to accomplish a sort of two-stage animation. However, when ordering in views, I do not ever manually set the frame of the views to where they are supposed to come from. Instead I let NSSplitView's adjustSubviews position them while wrapped in an NSAnimationContext with allowsImplicitAnimation:YES. Then I add additive compensation animations to make them appear to come from the correct place, and also to cancel out any animation from weird view sizing (for example if the window was resized, the ordered in view might not be the right size or place.) This kind of thing could not be handled by a one-key-enables-all property, and would need additive, the timing function, and the from and to values specified manually.

Received on Friday, 26 April 2013 05:50:00 UTC