Re: [css3-animations] multiple 'animation-name' and cascading

On Apr 12, 2011, at 12:53 PM, Tab Atkins Jr. wrote:

> On Tue, Apr 12, 2011 at 12:32 PM, L. David Baron <dbaron@dbaron.org> wrote:
>> On Tuesday 2011-04-12 11:33 -0700, Simon Fraser wrote:
>>> On Apr 12, 2011, at 10:29 AM, L. David Baron wrote:
>>>> On Tuesday 2011-04-12 08:56 -0700, Tab Atkins Jr. wrote:
>>>>> On Mon, Apr 11, 2011 at 9:09 PM, L. David Baron <dbaron@dbaron.org> wrote:
>>>>>> (Alternatively, I suppose one could check for whether the property
>>>>>> is specified in any keyframe -- though that's a bit more work.)
>>>>> 
>>>>> You need to check all the keyframes.  Given a keyframe like this:
>>>>> 
>>>>> @keyframes wobble {
>>>>>   0% { left: 0; top: 0; }
>>>>>  33% { top: 100px; }
>>>>>  67% { top: -100px; }
>>>>> 100% { left: 100px; top: 0; }
>>>>> }
>>>>> 
>>>>> In the middle third of the animation, the nearest keyframe blocks
>>>>> don't have any mention of 'left', but 'left' is still being animated.
>>>> 
>>>> The spec should perhaps mention that somewhere.
>>> 
>>> Agreed :)
>>> 
>>>> Additionally, it should say how that behavior interacts with timing
>>>> functions specified in keyframes.
>>> 
>>> In this case left animates exactly as if the middle two keyframes were missing:
>>> 
>>> @keyframes wobble {
>>>   0% { left: 0; top: 0; }
>>> 100% { left: 100px; top: 0; }
>>> }
>>> 
>>> If the first keyframe had a timing-function, then that's the one that would apply.
>>> 
>>> In other words, properties are interpolated between the keyframes
>>> that specify them.
>> 
>> This makes sense -- and seems better for authors -- but it surprises
>> me given that (a) the spec doesn't say this and (b) the spec says
>> that duplicate keyframes get dropped, which is part of what led me
>> to the model that I interpreted (and implemented) from what the spec
>> does say.
>> 
>> So given this model, it seems like it would make much more sense if
>> the spec also said that duplicate keyframes weren't dropped, but
>> were instead cascaded, so that, with:
>> 
>>  0% { left: 0; top: 0 }
>>  50% { top: 40px; left: 40px }
>>  50% { top: 25px; }
>>  100% { top: 100px; left: 100px }
>> 
>> you'd end up with top animating according to:
>>  0% { top: 0 }
>>  50% { top: 25px }
>>  100% { top: 100px }
>> and left animating according to:
>>  0% { left: 0 }
>>  50% { left: 40px }
>>  100% { left: 100px }
>> instead of having, as the spec currently says, left animating
>> according to:
>>  0% { left: 0 }
>>  100% { left: 100px }
>> because the second 50% keyframe overrides the first.

What's the use case for cascading keyframes?

>> 
>> In other words, I'd propose replacing the text:
>>  # If there are any duplicates, then the last keyframe specified
>>  # inside the @keyframes rule will be used to provide the keyframe
>>  # information for that time. There is no cascading within a
>>  # @keyframes rule if multiple keyframes specify the same keyframe
>>  # selector values.
>> with something that does specify cascading across different keyframe
>> selectors in the @keyframes rule.
> 
> I also agree that cascading the keyframes would be nice, though
> possibly for a different reason - as currently stated, you can't
> animate two properties starting from the same moment with different
> timing functions without silly hacks like starting one at 0% and the
> next at 0.001%.

Why not just use two animations?

If we allow cascading keyframes, it's not obvious that you could use separate
timing functions for different properties, since the timing-function property itself
would be affected by the cascade.

Simon

Received on Wednesday, 13 April 2011 01:18:25 UTC