Re: [css-animations] What happens if a @keyframes rule is added after the fact?

On 2014/07/04 1:18, Simon Fraser wrote:
> On Jul 2, 2014, at 7:14 PM, Brian Birtles <bbirtles@mozilla.com> wrote:
>
>> Hi,
>>
>> If I set "animation: doesntYetExist 10s" and, within 10s, add "@keyframes doesntYetExist { ... }" by script, what happens?
>>
>> a) The animation doesn't start
>> b) The animation starts from the beginning
>> c) The animation picks up from part-way through
>>
>>  From my testing, IE does (a) and Chrome does (b). Current nightlies of Firefox do (c).
>>
>> This question also relates to whether dynamic changes to keyframes are honoured. David pointed out several years ago that the spec says values are snapshotted but WebKit doesn't do this (and hence nor does Gecko) and that there may be good reasons for allowing dynamic changes to keyframes.[1]
>>
>> I think (a) is more in keeping with the current wording of the spec but if we allow dynamic changes to keyframes then either (b) or (c) would be possible.
>
> I think handling dynamic changes to the keyframes is tricky to do well; authors may expect some nice bridge between the current state given the old keyframes, and the new state given some possibly very different set of keyframes, which gets more complex with repeating and alternating.

I believe both WebKit and Gecko do a sudden jump from the old definition 
of @keyframes to the new with out any bridge in between. Are you 
suggesting they do something different?

> It seems reasonable for me to consider the animation start time to be the time at which there first exists an animation-name value pointing to a set of keyframes. That implies b).

That's certainly easiest to implement so I really hope everyone else 
agrees it is reasonable. :)

If I understand Tab's comment correctly, however, I think he was 
suggesting that if changing,

   @keyframes a { to { left: 100px; } }
   to
   @keyframes a { to { left: 200px; } }

preserves the start time of "animation: a 10s", then probably changing,

   <<nothing>>
   to
   @keyframes a { to { left: 100px; } }

should also preserve the start time?

That seems quite intuitive, however, the idea that we "consider the 
animation start time to be the time at which there first exists an 
animation-name value pointing to a set of keyframes" also seems like a 
fairly simple model to grasp.

It also saves answering the question of what events get dispatched, say, 
when the @keyframes rule is added after the animation has finished.

 > However, we’d have to consider whether a style change from an invalid 
set of keyframes to a valid set, or vice versa, would impact the animation.

What specifically do you mean by an invalid set of keyframes? If the 
@keyframes rule is valid but all the nested style rules are not valid I 
would imagine that the behavior there would be same as an empty keyframe 
list?

> c) makes me a little concerned about having to run animation logic for all elements with animation-name but no matching keyframes.

Yes, basically we'd have to create a dummy animation in order to track 
its start time and be careful to ignore it (whilst *not* ignoring 
animations which simply referred to an empty @keyframes rule).

 From a Web Animations API point-of-view too, I would expect that we 
would *not* return these dummy animations since they're not dispatching 
events and don't really exist.

(b) seems simplest to me. What do you think Tab?

Best regards,

Brian

Received on Friday, 4 July 2014 05:19:16 UTC