Re: [transitions] unfinished transitions v. elapsedTime

Hi Estelle,

I wonder if you can help working out the following issues:

On 2015/09/28 5:53, Estelle Weyl wrote:
> Taking http://codepen.io/estelle/pen/avZKEo as an example - with a
> delay of 1s and a transition-duration of 5s, if I mouseout .75s after
> the transition has started, Chrome waits the full delay, then takes the
> full duration - 5s - to revert back to the original state.
> [
> ] Firefox waits the full delay, but takes only .75s to revert to the
> origianl state.
> [
> ] The elapsedTime in Chrome is 5s, the elapsed time in FF is not exactly
> 0.75 seconds,… which seems to be a bug too.

How are you measuring the 0.75s of animation? You could be seeing a 
difference because the times are aligned to frame times, or because the 
transition doesn't start immediately (it waits until the first frame has 
been painted before starting).

> The elapsedTime issue is why I am mentioning transition-delay in this
> thread too. If the transition-delay is negative, I would assume the
> elapsedTime would be the transition-duration less the absolute value of
> the delay. If the delay is -1s with a 5s duration, i would assume the
> elapsedTime would be 4s. In chrome it’s 5s. In Firefox it is a number
> that makes no logical sense.

What number are you seeing? It should be equal to the duration of the 
reverse transition (not including the delay). In my testing it seems 
correct.

> The spec for ‘elapsedTime” reads “The amount of time the transition has
> been running, in seconds, when this event fired. Note that this value is
> not affected by the value of |transition-delay|.”, so definitely a
> positive value for a delay should have no effect. However, due to the
> “The amount of time the transition has been running”, i would assume
> that a negative delay DOES impact the elapsedTime, since it is how long
> the transition has been running.

I really have no idea what the use case is for elapsedTime so I don't 
know what the spec should say. It seems odd to me.

> In the reverse direction, starting midway thru an animation, I would
> assume that the elapsedTime is only the time the transition has been
> running. In this case, 0.75s. That is not what I am seeing.

I'm seeing 0.75s (roughly).

> If the elapsedTime is always the duration, as in the blink case, let’s
> change the spec to reflect that. However, I don’t think that is what the
> elapsedTime should be. I prefer FF’s implementation, even though the
> firing of the transitionend event seems to be a bit off in most cases
> (about 20 to 200ms off).

How is it off? How are you measuring when it should be fired? Perhaps 
this too is because the animation doesn't start until the first frame is 
rendered. If you want to get precise timing about when the animation 
started you need to use the Web Animations API.

I'd love to hear what the use case(s) is/are for elapsedTime if you 
happen to know.

Thanks,

Brian

Received on Monday, 28 September 2015 04:09:31 UTC