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

Hi Sylvain,

On Wed, Oct 23, 2013 at 6:31 AM, Sylvain Galineau <galineau@adobe.com>wrote:

>
>
> On 10/21/13 9:40 PM, "Steve Block" <steveblock@google.com> wrote:
>
> >> Indeed, I do not believe we ever clarified this
> >In that case, I think it would be good to update the spec to clarify this.
>
> Well yeah, no argument there.
>
> >
> >> So it's not clear whether animation-play-state: paused
> >> causes the delay to elapse and then freezes the animation; or if it also
> >> pauses the delay clock. The latter seems the better behavior for your
> >> specific scenario.
> >Agreed. I think that if you create an animation in the paused state,
> >you would expect that all aspects of the animation remain frozen until
> >it's unpaused.
>
> It seems reasonable; while some properties are expected to apply to the
> entire animation cycle e.g. many users do expect animation-play-state to
> pause a delay if need be, others are expected to be scoped e.g. the same
> users generally do not want animation-iteration-count to repeat the
> animation-delay. (At least not by default).
> I think the suggested behavior is not what browsers do at the moment; this
> may require a new keyword.
>

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.

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

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


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

Cheers,
    -Shane