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



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.

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

Received on Tuesday, 22 October 2013 19:31:40 UTC