RE: transitions vs. animations

Alex Mogilevsky wrote:

 > One fundamental difference between transitions and animations is
 > the definition of start and end state. Generally, it is like this:
 > 
 > 	(known state A) --> animation --> (no end state)
 > 	(known state A) --> transition --> (known state B)
 > 
 > A transition is an animation that adapts to specific start and end
 > state and transition time. An animation doesn't even have to have
 > an end state, and if it has one it generally can't be predicted
 > without running the animation.
 > 
 > Furthermore, transitions are actually triggered by end state:
 > 
 > 	(any state A) --> transition --> (desired state B)
 > 
 > This is useful in particular for backwards compatibility with
 > transition-unaware UA -- they will change the state, just no the
 > fancy transition. Also, since this is triggered by end state, and
 > declared at the same point with the end state, it doesn't need to
 > change when start state changes. That adjustment is automatic.

This is a good analysis. 

 > For the above difference, I think it is important to have a simple
 > way to declare a transition. It is probably possible to have
 > generic animations adjust to transition inputs but it seems pretty
 > complicated.
 > 
 > There is however a large number of cases where start and end of
 > transition is perfectly well known. Then specifying arbitrary
 > animation in place of transition in/out of a state seems very
 > desirable.
 > 
 > In Hakon's examples, I do like approaches where both animation and
 > transitions can apply. It could be something like this (slightly
 > modified):
 > 
 > /* start with a known static state - animations assume these start values */
 > .button {
 > 	position:relative;
 > 	color:blue;
 > 	left:0;
 > }
 > 
 > /* 1. transition */
 > .button:hover {
 > 	left: 10px;
 > 	color:red;
 > 	on-entry: transition(color, 1s), transition(left, 1s);
 > 	on-exit: transition(color, 1s), transition(left, 1s);
 > }

I like your functional notation. I suggest using a simpler function
name, though:

  on-entry: change(color, 1s), change(left, 1s);
  on-exit: change(color, 1s), change(left, 1s);

Having two properties ('on-entry', 'on-exit') instead of one (say,
'effect') is compelling. However, it will mean that the effects
triffer at different times. Consider this example:

  :hover {
    on-entry: play(bounce, 1s);
    on-exit: play(sway, 1s);
  }

  :focus {
    on-entry: play(bounce, 1s);
  }

If a hoveree becomes a focusee, the value of 'on-exit' will not
change, so 'sway' will not play; 'sway' will only play when the
element is no longer hovered.

This may be exactly what we want, or not. 


 > /* 2. custom animation */
 > .button:hover {
 > 	left: 10px;
 > 	color:red;
 > 	on-entry: animation(button_normal_to_hover); 	
 > 	on-exit: animation(button_hover_to_normal);
 > }	

Your example got me thinking. How about:

  :hover {
    on-entry: play(bounce, 1s);
    on-exit: play(bounce, 1s, reverse);
  }

Cool, eh?

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Monday, 5 April 2010 15:54:50 UTC