W3C home > Mailing lists > Public > www-style@w3.org > April 2010

Re: transitions vs. animations

From: Chris Marrin <cmarrin@apple.com>
Date: Wed, 07 Apr 2010 16:42:48 -0700
Message-id: <920FC5E6-2B80-4959-AAA2-6BDBC7D590D1@apple.com>
To: "www-style@w3.org list" <www-style@w3.org>

On Apr 7, 2010, at 4:27 PM, Håkon Wium Lie wrote:

> 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

Let me split this into two issues:

1) Unified syntax for animation and transition

Here you are incorporating the animation-name property into the single 'effect' shorthand. This gets rid of a few animation properties, but at the expense of readability and increased complexity. What does it mean if I specify direction or iteration-count for a transition? It just muddles the models for the expediency of removing 4 properties. You're really only getting rid of 2 properties if you consider the fact that you've added 2 functions (change and play). That doesn't seem like a reasonable tradeoff.

2) Additional ways of triggering an animation

This is a good feature to discuss. I just don't think "on-exit" and the related concepts are a clear way to express it.

Received on Wednesday, 7 April 2010 23:43:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:34 UTC