Re: Transitions and Animation merging: problem summary

First: thank you summarizing like this.

On Apr 15, 2010, at 1:24 PM, Simon Fraser wrote:

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

Can you give an example here of a use case that is not fulfilled?

>
> 2. on-exit/play-out animations
> 	

My thought is to not think about "on-exit" but only "on-entry" since  
every "exit" is also an "entry"

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

One idea that I half concocted but never finished is to have two or  
perhaps three pseudo-elements (I'll call them) defined inside the key  
frame definition.  I fear the browser implementors are going to fall  
out of their chairs but here goes...

Inside the @keyframes block, a "from", "to", and "diff" pseudo-element  
will be made available.  Each of these elements will have their style  
attributes available.  So, from.left, or to.right (syntax to be  
defined of course) would be available.  The author then uses calc to  
do whatever he wants to do.

>
> 		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?

I very much believe that we need an @keyframes concept for transitions  
or some way to mark an @keyframes as either an animation or a  
transition.

I also believe that we need a way to add other characteristics to an  
@keyframe to help with accessibility.  I believe that we need to allow  
the author to specify their reason or their intentions for the  
transition or animation.  This concept leads to perhaps that  
animations and transitions need stronger ties back to HTML since I  
gather that HTML is where the author's intentions are to be placed and  
CSS should be focused on just presentation.  But a twiddling beacon or  
a sliding box has a reason for being there that currently, as far as I  
know, the author can not explain to either the user or an agent like a  
screen reader.

Last, I'd like to consider if we can add sound to either transitions  
or animations or both as a unified part of the transition or animation.

Perry

Received on Saturday, 17 April 2010 02:37:05 UTC