Re: [css-animations][css-transitions] What is the intended use of elapsedTime?

On Wed, Sep 30, 2015 at 1:14 AM, Brian Birtles <bbirtles@mozilla.com> wrote:
> What is the purpose of the elapsedTime member on TransitionEvent and
> AnimationEvent. Are there specific use cases for it?

I presume that it's for the purpose of syncing up JS-driven things
with CSS-driven animations.

> I'm trying to define it in more general terms now that the Web
> Animations API and browser developer tools let authors seek time
> backwards and forwards but it's not clear what it is supposed to be used
> for.
>
> The definition in CSS Animations reads as follows:
>
>    "The amount of time the animation has been running, in seconds, when
>    this event fired, excluding any time the animation was paused.
>    For an animationstart event, the elapsedTime is zero unless there was
>    a negative value for animation-delay, in which case the event will be
>    fired with an elapsedTime of (-1 * delay)."[1]
>
> I have a bunch of questions but most of them probably come back to,
> "Is this value supposed to be independent of the frame rate at which the
> animation was sampled?"
>
> For example, if an animation runs for 3s and the first frame after
> the animation ends occurs at 3.1s, does elapsedTime on animationend
> report 3 or 3.1?

animationedend should report 3, definitely.  That's when it ended.
That's a different issue than events firing *during* an animation.

> We could go a couple of different ways here:
>
> A. elapsedTime represents the animation time if the animation was
>    sampled at an infinitely fast rate (i.e. 3).
>
>    This approach provides consistent values regardless of the
>    performance of the underlying system. However, it opens up all sorts
>    of other questions:
>
>    1. If the magnitude of negative delay is greater than the animation
>       duration, do we clamp the elapsedTime to the duration?

Delay and duration don't have anything to do with each other.  Am I
missing something from this question?

>    2. If the author seeks backwards past the beginning of an animation
>       with a negative delay and then plays forwards, presumably the
>       animation starts from its natural beginning and dispatches an
>       animationstart event at that time with elapsedTime = 0.
>       Doing that, however, feels like saying the elapsedTime depends on
>       when the animation is sampled which seems at odds with this
>       approach.

I'm not sure I understand.  In the case of a normal negative-delay
animation, we can't actually go back in time to fire the
animationstart event, so we fire it at soon as we start applying the
animation, and let you know that this "start" actually began a certain
distance into the animation.  (start is the only thing that's weird
like this, because we guarantee it's fired even if you never
experience the "start" moment of the animation.  Other events only
fire if you actually play through their associated moment.)

>    3. As an extension of the above, if an animation finishes then the
>       author seeks backwards to the middle of its interval then I
>       expect it fires an animationstart event to indicate it is now
>       animating again.[2] In that case should the elapsedTime be 0
>       (assuming there is a zero/positive delay) or should it be based
>       on the time seeked to (similar to the negative delay case)?

It should be based on the time seeked to, matching the behavior of a
negative delay, because it's doing something similar - beginning the
playthrough of an animation at a time other than the actual start
moment, and again, we can't go back in time to fire the animationstart
at the correct time, but it's still valuable to be informed that it
started.

> B. elapsedTime represents the difference between the current frame time
>    and the start time of the animation (i.e. 3.1).
>
>    This is more simple but I wonder if it is useful.
>    If you're running on a slow device you'll get completely different
>    times. The animationstart event might fire after the animation has
>    finished and the elapsedTime might be greater than the animation
>    duration. In that case, I don't know what it is used for.

No, this is wrong.  Any event which has a defined moment to occur at
(iteration events, etc) needs to report that time, because that's when
they were queued (in the absence of a slow main thread).

~TJ

Received on Wednesday, 30 September 2015 21:30:39 UTC