Re: [css-animations] Starting animations with animation-play-state: paused



> From:  Shane Stephens <shans@google.com>


> Hi Sylvain,



> Firefox and Chrome do apply animation-play-state to animation-delay
>(e.g., if an animation is created in paused state, any animation-delay
>will apply after that animation
> is unpaused). I can't test Safari or IE at the moment.

Same in Safari and IE11 so that doesn't seem to be an issue.

> I'm not sure what you were referring to as the suggested behavior :)

Pausing the entire animation, including delay. I thought there were some
interop issues regarding the scope of the paused state. It appears I was
wrong.

> If a negative animation-delay is applied, Firefox will display the
>effect of the animation even if paused. This remains true even if new
>values of animation-delay are set
> while the animation is paused - Firefox will update the effect of the
>animation to
> take the new delay value into account (this seems to violate the spec.
>Isn't delay frozen for animations that have been created?).
> Chrome does not currently do this (animations do not update while
>paused, and jump to the appropriate value once running).
> However, we are intending to change the behavior here to harmonize with
>Firefox and Web Animations (the part that doesn't violate the spec, at
>least).
 

This is indeed unspecified.

>
>There's also the question of whether an animation which is created in
>the paused state should immediately fire its start event if the delay
>is non-positive. I think it's clear that firing the start event should
>be tied to displaying the first value, so if we're to specify that
>such an animation should immediately display a value, I think it
>should also immediately fire the start event.


>> It's not obvious to me that an animation created in the paused state
>> should fire a start event; I think I'd rather see a paused event fired.
>> Start events would occur whenever the initial delay elapses or whenever
>> the running animation is unpaused (including when an animation created
>>in
>> the paused state is finally resumed).

> I agree with Steve: whether a start event is fired should match when the
>animation enters its active region,
> regardless of paused state. This seems most consistent. Note that
>Firefox does not currently do this.

It seems most consistent with what? The start event is generally used to
trigger some other effect or processing associated with the beginning of
the animation. In particular, I might want to create an animation in the
paused state and then, based on user interaction (which could be a :hover
or :active), set it to running. Only then do I want my start event
listener to initiate some other related change. But if the start event can
fire immediately and independently of the animation actually running then
my event listener better also check for animation-play-state. Except it
won't be called again when the animation is actually un-paused. This makes
the event less useful imo.

I think your interpretation of start is: "Some frame of the animation is
visible; whether the animation timer is also running is irrelevant". I do
not think the spec explicitly supports this interpretation. Though it does
not explicitly exclude it either I do not understand why this would the
more useful behavior for authors. If an animation is 'paused at birth' I
think authors expect the start event to not fire until it is first set to
running, regardless of the sign of animation-delay. In addition, I think
authors may want to listen for pauses and resumes.

Note that the first frame of the animation may also be visible during a
positive animation-delay i.e. using animation-fill-mode. Since the visual
state of the animation is in its 'active region', do you think we should
fire animationstart as soon as the animation is applied in this case?

Received on Tuesday, 22 October 2013 22:16:46 UTC