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

Re: transitions vs. animations

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 07 Apr 2010 00:05:06 -0700
Cc: Chris Marrin <cmarrin@apple.com>, "www-style@w3.org list" <www-style@w3.org>
Message-id: <9E2B3161-8D5F-4340-9A7B-6B62398F6980@apple.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

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.  
Right now transitions and animations have both a difference in purpose  
(state change animation vs. ambient animation) and a difference in  
functionality (simple bezier only, vs defined keyframes). This could  
lead to using animations solely for keyframe functionality when a  
transition may be better. I recognize that specifying keyframes for  
transitions is in some ways more challenging, but I think it is a  
challenge worth tackling at some point.

Also, and for the record, I think the concepts of transitions and  
animations should be kept separate. Transitions animate a state  
change. Animations are ongoing animations that are themselves tied to  
a state. A button that pulses continuously is, to me, clearly a  
different use case than, say, a highlight bar which can be in one of  
10 positions and needs to be able to animate up or down in steps when  
it changes position.

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.

Received on Wednesday, 7 April 2010 07:05:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:44 UTC