Transitions and Animation merging: problem summary

Let me try to summarize the problems that we've observed when trying
to merge transitions and animations, and highlight some of the edge
cases that I don't think have been sufficiently considered in the
various proposals.

1. Implications of combined transition/animation:

	With a combined transition/animation property (like "animate" or
	"effect") we initially run into the issue of what exactly
	triggers the behavior. One possibility is to trigger on changes
	to the animated property, just as transitions do today. This
	alone does not fulfill the use case of running an animation
	(without any persistent property change) when styles change on
	an element.

	The second possibility is to run when the "animate" or "effect"
	property itself changes. This is similar to what the existing
	Animations draft describes. If we had only this behavior,
	authors would end up adding a lot more animation rules to their
	stylesheets than they have to for transitions, since in every
	place that they change 'left' now, they would also have to put
	'animate' rules.

2. on-exit/play-out animations
	
	It has been suggested that a requirement of transitions /
	animations should be that it's possible to run an animation when
	exiting a "state". The proposals include "play-out", "on-exit"
	and "animate-out" properties.
	
	These all share some serious issues:

	* Running an animation when a property _ceases_ to apply leaves
	no active style in the document that relates to the running
	animation. There's no way for script, for example, to
	getComputedStyle and figure out if anything could be animating.
	
	* There's no way to ensure that no animations are running by
	manipulating style. This is a serious issues for accessibility,
	and I think will be a headache for authors (imagine scenarios in
	which an elemnt rapidly changes from various states to a final
	state, and the author needs to ensure that the element is not
	animating when entering the final state).

	* Arbitrary rules are required to describe whether on-exit
	animations are overridden by subsequent on-entry animations.
	
	* There's ambiguity about whether animation-duration properties
	are taken from the old or the new style with on-exit animations.
	Transition properties are taken from the target style; it would
	be odd if this was not the case for on-exit animations.
	
	* animation-play-state cannot be used to pause on-exit animations.

2. Keyframes for transitions

	There are two applications of keyframes for transitions:

	1. Allow keyframes to provide a more complex timing curve for
	   just the property being transitioned. I'll call these
	   "transition keyframes".
	   
	2. Allow keyframes which affect arbitrary properties. This is effectively
	   triggering keyframe animations from transitions. I'll call these 
	   "triggered animations".

	Transition Keyframes
	
		Allowing keyframes for transitions seems like a simple
		extension of transitions, but we don't believe that authors
		will find it useful much of the time. The end points of a
		transition are described by existing property values, so
		authors need to be able to write keyframes that can be
		relative to these existing start and end points. This would
		require a new set of "relative" units, or unexpected
		property-unit pairing ("color: 20%").

		The absolute-only @profile and other proposals don't address
		this.
		
	Triggered animations
		
		Triggered animations allow authors to run keyframe
		animations when a transition would normally trigger. We want
		to avoid authors having to trigger a transition by faking
		values, just to get an animation to run, so triggered
		animations are not a good replacement for the existing
		Animations proposal.

		Also, if we allow animations to run in a similar way to how
		transitions run, we need to determine how the existing
		animation-duration (or period), animation-play-count etc.
		properties apply. Should such an animation be allowed to run
		longer than the associated transition?

3. Keyframe reversal
	
	It has been suggested that it should be possible to re-use a set
	of  @keyframes in reverse.

	We think that in many cases this will not produced the results
	that the designer intended; keyframes often describe a
	non-symmetrical  motion that does not feel right when reversed.

Simon

Received on Thursday, 15 April 2010 18:25:33 UTC