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

Re: transitions vs. animations

From: Dean Jackson <dino@apple.com>
Date: Tue, 23 Mar 2010 08:54:08 +1100
Message-Id: <5A264E33-CE5C-4E9C-8FA1-675916039D88@apple.com>
To: "www-style@w3.org list" <www-style@w3.org>

On 20/03/2010, at 10:49 AM, L. David Baron wrote:

> On Friday 2010-03-19 16:22 -0700, Simon Fraser wrote:
>> Tying transitions and animations together would very much restrict the flexibility of both,
>> and unnecessarily constrain what authors can do.
> 
> I'm not sure that it's that constraining.
> 
> For example, I could imagine merging the properties as follows:
> 
> * combine animation-name and transition-property using a functional
>   syntax, like:
>     animation-???: transition(color), keyframes(wobble)
>   where 'animation-???: transition(color)' == 'transition-property: color'
>   and 'animation-???: keyframes(wobble)' == 'animation-name: wobble'

Replying late into the thread, but I'd like to say that I'm not a big fan of this approach. What it seems to be doing is using functional syntax as a labelling mechanism (which, aside, it is in some places such as url() but is more of a function in things like gradient()). IMO, you're moving the declaration of intention from the property name into the property syntax.

This might seem like a good idea because it reduces the number of properties, but it means the property syntax is more complex for little extra benefit. I believe it is a better authoring story to restrict properties to name = value. 

Other than that, I unsurprisingly agree with Simon's points that animations and transitions are separate concepts, and should remain as such. David's note below about cascade clashes is important - I often add transitions to existing content at a high level (eg. .bubble { transition: opacity 1s; } ) and then animations on specific elements ( #bouncingbubble { animation: bounce 2s infinite alternate; }). Munging the properties together makes this natural approach to authoring a lot more tedious.

Dean

> 
> * make animation-duration, animation-delay, and
>   animation-timing-function (and maybe also animation-play-state,
>   if it's kept) apply to both types of animations (keyframe and
>   transition)
> 
> * make the other animation-* properties have no effect on
>   transition animations (only affect keyframes)
> 
> Doing something like this would slightly increase the damage caused
> by not having an additive cascading mechanism, but that's a problem
> that's already present with both transitions and animations
> separately.  We should probably be thinking about adding an additive
> cascading mechanism:  it's useful here, for the opentype font
> features, for counters, and likely a bunch of other things I'm
> forgetting.
> 
> -David
> 
> -- 
> L. David Baron                                 http://dbaron.org/
> Mozilla Corporation                       http://www.mozilla.com/
> 
Received on Monday, 22 March 2010 21:54:43 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:25 GMT