Re: [web-animations] Web Animations minutes, 18 / 19 June 2013

Thank you for considering the additive animation usage pattern that I call "seamless" and for mentioning the "perfect" timing function at the last meeting, even if it was as a concern. I would like to reiterate its importance, intended for heavy layout of things like an isotope.js grid or animating editable text, and introduce a new keyframe animation technique. To the uninitiated, the underlying value is instantly changed and an additive negative delta animation with no fill is added. This moves the element back to where it came from then animates to zero. It allows for many concurrent animations and is in my opinion the best pattern for responding to user interaction. My biggest concerns with the spec are there is no guarantee that adding animations can happen at the same time as setting the underlying value, and the intended use has final state determined by a forward filling animation instead of the underlying value.

The API uses element.style in its implementation, which gave me some difficulty as I wanted to use it as well. The suggestion was to use document.styleSheets[].rules[].style, which I find awkward. However, the real problem is neither could be synced with added animations. I attempted an alternate approach, using a non-additive animation that fakes the setting of the underlying value. The API allows animations to have the same start time, unfortunately there is still flickering which I suspect is a redraw between calls to replace() and play(). 

The additive pattern received some criticism, in particular the requirement that it use cubic-bezier(0.5, 0.0, 0.5, 1.0) to hide the seams. To-animations are very impressive, but I have to point out it is impossible to blend timing functions when performing path smoothing of animations that start at different times. For example, consider something like cubic-bezier(1.0, 0.0, 1.0, 1.0), which I call "crazy ease in". This is probably not desirable for layout of my expected use case anyway. While unrelated to timing functions, a drawback of to-animations are that instant changes to the underlying value are not visible while animations are running.

Describing physics was the other stated timing function related concern at the meeting. However, I believe the "spring/bounce" effect which I have seen discussion about should cause the same concern and might be better described as keyframes instead of a timing function. A very convincing argument for the additive usage pattern is that complicated keyframe paths can be described relatively. Many, many additive keyframe animations can run concurrently and blend together. This first example shows four different types of animation for comparison, with css transitions in blue, to-animations in purple, additive in green, and additive keyframes in orange. The instructions are initiate dragging both outside or inside the dot. It performs best using Chrome when on OSX and horribly on Safari.

http://jsfiddle.net/NphZR/embedded/result/

This next one shows additive width change. The instructions are drag back and forth horizontally below the bars. This example is the easiest to see the offending flicker.

http://jsfiddle.net/yeveU/embedded/result/

This next one shows instant, un-animated changes at the same time as running animations, implemented as rotation. The effect is not possible with CSS transitions or to-animations without nesting elements. The instructions are move the mouse horizontally while alternating mouse down and up.

http://jsfiddle.net/Ds2GG/embedded/result/

Next is a fiddle which shows a bug with additive scale transforms. An additive scale animation from 0 to 0 should result in an unchanged scale of 1. Animations from 0 to 0.25 or -0.25 should result in a scale of 1.25 or 0.75, and one combining both should result in a scale of 1. It is only 2d as I didn't have enough time to come up with good tests and figure out the result of a combined translateZ and scaleZ. 

http://jsfiddle.net/zQ6n3/embedded/result/

I also found problems with 3d rotation as well. Additive animation destinations of 0 degrees fail for rotateX and rotateY. Of course, both of these tests need review as I could be wrong.

http://jsfiddle.net/ucEWr/embedded/result/

I played with web-animations.js and was able to fix the flickering problem. In CompositedPropertyMap's applyAnimatedValues() I simply provided a different baseValue, but also for clearValue() as well, providing a destination value instead of null. Unfortunately it was a conceptually dubious and ugly hack, a desperate attempt to be able to use element.style and achieve syncing. I thought the API could use the ability to pass a dictionary of destination values, somewhere.

Forgive me for not being fully aware of all the issues dealing with the underlying value as it relates to css and wherever this is going to be applied to in the future. For now I am going to focus on syncing, and any alternative way would work. I have always been partial to Core Animation's transactions. Would it be possible to replicate them to temporarily prevent requestAnimationFrame and the ticker from redrawing? This is probably what I will be attempting next.

The future of user interface animation on the web needs relative animations that run concurrently, allow for simultaneous instant changes, and do not fill forward, but instead are removed when finished and leave state solely dependent on the underlying value. The web-animations API is the first time I have been able to get anything close so I am grateful, thank you.

Received on Thursday, 25 July 2013 12:07:15 UTC