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



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

> (I rearranged your questions to make them easier to reply to)

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

> No, my interpretation of start is that it should fire when an animation
>stops being inactive or filling, and starts being active - i.e. the
>animation is interpolating.

My interpretation is that the paused state prevents it from interpolating;
it only interpolates while animation-play-state is running.
The question here is really which one is most consistent with author's
expectations, and most useful.


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


> No. This is filling, not active.

The filling needs to interpolate the first frame i.e. compute the
properties of that frame and apply them. It's clear you think the
difference obvious; given your web animations work you probably have a far
more complex mental model of this stuff than most CSS Animations users. Or
me.

 

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



> Given that this can only produce a difference when the user has
>specified a negative start delay and paused the animation, I don't find
>your use case particularly
> compelling.

The subjective appeal of a use-case is not a good reason to make the
platform appear broken to authors in some scenario; not without a good
reason e.g. the implementation cost would be out of proportion with likely
use and implementors are reluctant to go there even if said use estimate
were way off. 

But since negative delays can be used - and are used - to start animations
from a certain point I don't think it's crazy to conceive an app may want
to 1) set the play state to pause 2) pick some interesting starting point
using a negative delay 3) then later set the play state to running and
expect the start event to do its job. At the very least, I would like to
hear a more, um, compelling reason for breaking this expectation than
'Shane Stephens thinks this is boring'?


> In almost all cases there won't be any delay (or, somewhat less commonly
>a positive
> delay), and in these cases the start event won't fire until the
>animation is un-paused and the interpolating (active) region of the
>animation starts.

Precisely why I'd lean on the side of preserving the author expectation we
do create in most cases. It is extremely frustrating for authors to find
out that a behavior they've been able to trust dozens of times breaks
apart the day they get a little bit fancier. 'Well, it conforms with the
spec' only adds insult to injury, really.

So instead of arguing arbitrary shades of compellingness, any reasons it
can't work that way? Is it because by the time animation-play-state
property is resolved to pause some tiny amount of elapsed time might have
gone by? Something else?

Received on Wednesday, 23 October 2013 01:32:20 UTC