W3C home > Mailing lists > Public > www-style@w3.org > October 2015

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

From: Brian Birtles <bbirtles@mozilla.com>
Date: Thu, 1 Oct 2015 10:36:16 +0900
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "www-style@w3.org" <www-style@w3.org>
Message-ID: <560C8E10.90404@mozilla.com>
Hi Tab,

Thanks for getting back to me!

On 2015/10/01 6:29, Tab Atkins Jr. wrote:
> 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.

That seems to contradict the idea that it's frame-rate independent, 
right? If the time reported is the ideal time, not the actual progress, 
then you can't use it for syncing things up, right?

For example, if I have an animation of duration 3s that repeats twice, 
and I get a frame after 3.1s, and I generate an animationiteration event 
with elapsedTime 3s then I think that doesn't help you sync up with the 
animation's actual progress.

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

I'm not sure what that means. Are you suggesting the behavior is 
different for animationiteration? Or animationstart?

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

In this case, the animation finishes before it starts. As the spec 
currently reads, you'll get an animationstart with an elapsedTime of 
-delay and an animationend of duration. e.g.

   animationstart, elapsedTime: 4
   animationend, elapsedTime: 3

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

With developer tools or the Web Animations API we can go back in time to 
fire the animationstart event a second time. On that second time around, 
we'd presumably use an elapsedTime of zero.

So in effect I think we end up with a flag indicating that we seeked 
into the animation when we started it and hence we need to adjust the 
elapsedTime based on that seek time.

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

I think this approach is actually more useful if elapsedTime is to be 
used for synchronizing since it tells you the actual progress of 
animations at the current frame. That said, I don't think that's what 
the spec intends.

Best regards,

Received on Thursday, 1 October 2015 01:36:47 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:54 UTC