Re: transitions vs. animations

Maciej Stachowiak wrote:

 > >    So, to conclude, the effects are not tied to "states". Rather, the
 > >   effect trigger when the value of the 'effect' property changes for a
 > >   given element. When this happens, the respective 'on-exit' and
 > >   'on-entry' effects will be shown.

 >    I think triggering when the "effect" property changes is not as clean
 >    and convenient as triggering implicitly when the value of an animated
 >    property changes, as transitions do currently.

This is the best argument I've heard so far. Indeed, it would be hard
to determine which changes happen "simultaneously enough" to be
considered a transition.

Accordingly I have revised my proposal slightly so that transitions
(called 'change effects' in my proposal below) are triggered by
changes in property values. As such, the revised proposal is closer to
the current specification. 

There are a number of differences, though:

  - the syntax is more readable for humans (at least this human)
  - only one set of properties is needed
  - animations can also be played 'on-exit', thereby capturing the
    "blue bouncy box" use case (3b in the link below)

Here is a set of use cases and a comparison of the syntax used in the
two models:

   http://people.opera.com/howcome/2010/ta/index.html

And here's a more formal write-up of the proposal:

   The 'effect' property

   The 'effect' property accepts a comma-separated list of effects as
   value. Each effect must contain on change() or play() function in
   addition to optional other values. An effect is referred to as a
   'change effect' or a 'play effect'.

   The change() function takes a property name as value. A change
   effect indicates that the specified property should be monitored;
   whenever it changes, the change effect will be shown. The length of
   the change, the delay of the change, and the timeing function of
   the change can be specified. For example, this declaration
   specifies that the change should take 1s, there should be a 0.2s
   delay for both changes, and the 'ease-in' timing fuction should be
   applied: 

     effect: change(left) 1s 0.2s ease-in;

   The play() function takes the name of an animation as value.
   Animations are specified in separate @keyframes constructs. Unlike
   change effects, play effects are not triggered by value changes
   other properties, but rather by value changes on the 'effect'
   property itself. When an element is assigned a new value on
   'effect' property, the value is examined and any effects set to
   start immediately are started, while effects with delayes are
   sceduled to be started later. Further, any effect marked to start
   'on-exit' on the previous value is started. For example, this rule
   specifies that the 'bounce' animation should be played twice: when
   the 'effect' value is first set, and when the 'effect' value is
   reset the animation is played in reverse:

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

   Or one could write:

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

   The 'on-entry' can be considered to be a delay equal to 0. 

   The 'reverse' keyword is offered as an alternative to the proposed
   'alternate' keyword.

   The 'during' keyword (see the use cases) is offered as an
   alternative to the proposed 'infinite' keyword.

   If a functional notation is considered too difficult for scripts to
   deal with, it can be dropped. This will result in possible
   namespace conflicts between properties and animations. (But that
   conflict already exists in the current specs; we will, e.g., never
   be able to create a property called 'alternate' without conflicts.)

   If a functional notation is acceptable, one may consider putting
   more values inside the function. E.g: 

     effect: change(color, 1s);

Cheers,

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

Received on Wednesday, 7 April 2010 23:27:57 UTC