Re: transitions vs. animations

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. 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.

Transition keyframes have been discussed quite a bit. The reason for leaving them out (and I think it's a good reason) is because it would require some sort of new value notation in CSS. You'd need to specify the transition keyframes in terms of the from and to property value. You can't use '%' because that notion is already used in CSS. So you need new syntax, new value types and new semantics about where this new syntax can be used and how it is applied. I think there is some value in transition keyframes for some applications. But I don't think it's nearly important enough given the work to define it. Perhaps later, but I don't think it should be included in this revision of the spec.

> 
> 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 agree. I think we need to have better semantics for triggering animations, to enable Simon's "slide+bounce" use case and to bring animation semantics closer to that of transitions. But I think that can be done using the current model.

> 
> 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.

Right better animation triggering semantics would address that case as well.

-----
~Chris
cmarrin@apple.com

Received on Wednesday, 7 April 2010 17:40:18 UTC