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

Re: transitions vs. animations

From: Brad Kemper <brad.kemper@gmail.com>
Date: Wed, 7 Apr 2010 06:37:16 -0700
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Chris Marrin <cmarrin@apple.com>, "www-style@w3.org list" <www-style@w3.org>
Message-Id: <D9FD5DB7-B0D8-4C40-8AE7-09B955AB1E39@gmail.com>
To: Maciej Stachowiak <mjs@apple.com>

On Apr 7, 2010, at 12:05 AM, Maciej Stachowiak wrote:

> On Apr 5, 2010, at 3:32 PM, Tab Atkins Jr. wrote:
>> I'm not combining animations and transitions in general.  I'm
>> separating them further!  I am, however, allowing keyframes in
>> transitions, to address a use-case that we identified and that can't
>> be done well with the current draft.
> I like the idea of supporting keyframes for transitions in some form.

My favorite so far for that is to have that keyframe animation completely self contained within a 'play()' function (taking the same arguments as the value of the 'animation' shorthand), assigned to a 'transition-[something]' property (such as 'transition-triggered-animation'). It's clean and simple and easily understood, and consistent with the separate 'animation' property.

> [...] Also, and for the record, I think the concepts of transitions and animations should be kept separate.

I second that. They are distinct, and the attempts to combine them have just made them messier and more confused.

> Transitions animate a state change.

Any state change at all, or even a class change. It is more-so tied to a value change.

> Animations are [...] tied to a state. 

> I also think there is use case not served very well by either currently, which is one-shot animations without a distinct end state. For example, an item that bounces once and returns to the original position when clicked, as suggested earlier in this thread.

**transitions: attached a value change
**animations: attached to a state (including unadorned selectors and, perhaps, the state of a transition taking place)
**third thing (if I understand correctly): attached to an event (mousedown, mouseup, submit, etc.)

I am not at all enthusiastic about that third thing. It seems like we are trying to recreate DOM events (onclick, onsubmit, etc.). The 'play-out' (and brothers) as part of transitions feels messy and unclear to me. I'd be OK with leaving specific event handling to JavaScript, and only use CSS to animate value changes (transitions) and steady states (@keyframes animations).


Received on Wednesday, 7 April 2010 13:37:56 UTC

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