Re: transitions vs. animations

I wrote:

 > Looking at some simple examples, I wonder if it's possible to fold
 > transitions into animations [3] and thereby get rid of the word
 > "transitions".

We had a productive discussion on this topic at the CSS WG F2F meeting
in Cupertino. I think there's general agreement that:

  - transitions are simple, elegant, and they fit nicely into the CSS
    architecture

  - animations and keyframes are powerful...

  - ... but there are some common use cases that cannot be described

  - it would be nice to combine the best of both models into one
    model, if possible

  - some people sometimes confuse the term "transition" with
    "transform"

  - the specs are eager to progress, so comments should arrive sooner
    rather than later

This message is an attempt to write up my own thoughts on the subject,
and to present a syntax (several, actually) that fulfills the goals
above.

First, let's find a placeholder term that is neither "transition" nor
"animation". This allows us to continue using "transition" and
"animation" as they are used in the current drafts. I'll use "effect"
in this message.

Then, let's create a simple example to ensure that the simple stuff is
still simple. Here's a common use case that turns blue into red over
the course of 1s when an element is hovered over:

[example 1]

  a { color: blue }

  a:hover {
    color: red;
    effect: color 1s;
  }

So far so good; the values on the 'effect' property are identical to
the values on 'transition' in the current draft.

Now, let's attack the bouncy blue box use case. It consists of a blue
box that is pushed to the right when it is hovered over. In the course
of moving rightwards, it also bounces up and down. When the hovering
ends, the blue box will move back to its original position, while
performing the bouncy vertical movements yet again. This use case can
almost, but not quite, be described in the current drafts. Let's see
if we can find a way to address this. 

Let's look at the bouncy movements first. They are best described
using a separate @-rule:

[example 2]

  @keyframes bounce {
    from { top: 0; }
    33%  { top: -20px; }
    66%  { top: 20px; }
    to   { top: 0; }
  }

This is identical to the syntax in the current draft. 

Then we have to attach this animation to two events: when the element
is hovered over, an and when it is un-hovered over. We'd like to do
this without adding an event model to CSS. Let's make up a syntax:

[example 3]

  .blue-box:hover {
    effect: on-entry bounce 1s, on-exit bounce 1s;
  }  

The above uses two new keywords: 'on-entry', 'on-exit'. These are
values on the 'effect-delay' property. That is, 'on-entry' is equal to
0 in the current draft so that the animation starts immediately when
hovering occurs. The 'on-exit' keyword has no numeric equivalent, but
is interpreted to mean that the delay should last until un-hovering
occurs. In both cases, the effect will last for one second. 

One potential problem in the above syntax is that the name of the
keyframe definition ("bounce") may clash with the name of a property
(if, say, a "bounce" property is added in the future). One solution to
this is to add a functional notation. E.g.:

[example 4]

  .blue-box:hover {
    effect: on-entry play(bounce) 1s, on-exit play(bounce) 1s;
  }  

or perhaps:

[example 5]

  .blue-box:hover {
    effect: on-entry do(bounce) 1s, on-exit do(bounce) 1s;
  }

The effects described in example 4 an 5 only adds vertical bouncing,
there is no horizontal movement. Let's add that to the mix:

[example 6]

  .blue-box:hover {
    left: 700px;
    effect: on-entry left 1s, on-exit left 1s, 
       on-entry play(bounce) 1s, on-exit play(bounce) 1s;
  }  

The example above can be cut down a bit by relying on default values:

[example 7]

  .blue-box:hover {
    left: 700px;
    effect: left 1s, on-exit left 1s, play(bounce) 1s, on-exit play(bounce) 1s;
  }  

In the above example, the 'on-entry' keyword has be removed as
effects, by default, start on entry. The result is a shorter, but
slightly less readable syntax.

Instead of the 'on-entry' and 'one-exit' keywords, it may make sense
to have properties for effects that start on entry and exit:

[example 8]

  .blue-box:hover {
    left: 700px;
    effect-on-entry: left 1s, play(bounce) 1s;
    effect-on-exit:  left 1s, play(bounce) 1s;
  }

One difference between this proposal and the current specs is that it
matters where the 'effect' property is set. For example, in the
current specs, the following two examples have identical results (I
believe):

[example 9]

  a { 
    color: blue;
    transition: color 1s;
  }

  a:hover {
    color: red;
  }

or:

[example 10]

  a { 
    color: blue;
  }

  a:hover {
    color: red;
    transition: color 1s;
  }

However, in this proposal the 'effect' property must be set on the
:hover element, as in example 1:

[example 1]

  a { color: blue }

  a:hover {
    color: red;
    effect: color 1s;
  }

That is, in this proposal the effect isn't triggered by a change in a
property value (as is the case for transitions), but rather the
effects are described on the 'effect' property. In practice, I
believe, one can express all current transitions by setting/changing
the value of the 'effect' property.

But I may have overlooked something. 

Finally, I'd like to show what the proposal looks like with the
property name changed from 'effect' to 'animation':

[example 11]

  .blue-box:hover {
    left: 700px;
    animation: on-entry left 1s, on-exit left 1s, 
       on-entry play(bounce) 1s, on-exit play(bounce) 1s;
  }  

[example 12]

  .blue-box:hover {
    left: 700px;
    animation: left 1s, on-exit left, play(bounce), on-exit play(bounce);
  }  

[example 13]

  .blue-box:hover {
    left: 700px;
    animation-on-entry: left 1s, play(bounce) 1s;
    animation-on-exit:  left 1s, play(bounce) 1s;
  }

Also, the 'keyframe' name may be changed. Perhaps to:

[example 14]

  @animation bounce {
    from { top: 0; }
    33%  { top: -20px; }
    66%  { top: 20px; }
    to   { top: 0; }
  }

In sum, I think this unified model is worth considering. But I may
have missed something. Naturally, comments are welcome.

Cheers,

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

Received on Saturday, 3 April 2010 08:07:44 UTC