Re: [csswg-drafts] [css-animations] Clarify or remove elapsedTime

To summarise discussion so far:

## Is the time the idealized elapsed time or the actual elapsed time?

For example, suppose the next iteration of an animation is scheduled 
to occur at 10s after the animation started. However, suppose the 
animation frames occur at 9.9s and 10.1s, we'll dispatch the 
`animationiteration` event at 10.1s. At that point should 
`elapsedTime` be 10 or 10.1?

When I've [asked about this in the 
past](https://lists.w3.org/Archives/Public/www-style/2015Sep/0304.html)
 I was told it should be the ideal elapsed time, i.e. 10.

This, I'll note, does not agree with the definition of `elapsedTime` 
used for the `animationstart` event when there is a negative delay, 
i.e. `abs(animation-duration)`. If we were reporting the ideal 
`elapsedTime` in that case we should report zero.

Furthermore, with regards to use cases for the `elapsedTime` one 
response was:

> I presume that it's for the purpose of syncing up JS-driven things 
with CSS-driven animations. 
[[1]](https://lists.w3.org/Archives/Public/www-style/2015Sep/0323.html)

However, the ideal elapsed time is useless for this since what you 
really want to know is, "where is the animation up to _now_?", not 
where it would be up to in an ideal world with an infinite sample 
rate.

Another response was:

> This is (probably) used to determine how many iterations have 
happened. 
[[2]](https://lists.w3.org/Archives/Public/www-style/2015Oct/0226.html)

That seems more understandable although if that were really the use 
case we should have just added a `currentIteration` member to the 
event and spared authors from having to divide by 
`animation-duration`. Furthermore, if we introduce something like Web 
Animations' [iteration 
start](https://w3c.github.io/web-animations/#iteration-start) to CSS 
this technique of dividing `elapsedTime` by `animation-duration` no 
longer works.

## Can we just drop `elapsedTime`?

>From my searching of GitHub, it seems we probably can't. To be fair, 
most of the useage on GitHub is:

* debugging code of some sort, typically just dumping the value to the
 console for no obvious reason (e.g. 
[[3]](https://github.com/ambac13/ambac13.github.io/blob/fa9e4eb69dbb6daeff9a76fa1e10f015f77344c1/animation.js),
 
[[4]](https://github.com/racsocode/administrador/blob/df1abc8029bfccafdbda2f277ae3c982605d6310/public/js/banner.js),
 
[[5]](https://github.com/sigon426/app-preciocarburante/blob/ba2dd4bcdcb5241b8501268aecacab3ee0dbb05e/public/js/textAnimation.js),
 
[[6]](https://github.com/daclouds/dxd/blob/afcd2fa25aa5d08aabb0484cd48474dcd2fc9012/animations/basic/main.js))
* simulating events (e.g.  
[[7]](https://github.com/nathanfaucett/virt-dom/blob/2bf48869499cb7d342ecb8a3992a95fe2d6fd73d/src/events/getters/getAnimationEvent.js))
* test code (e.g. 
[[8]](https://github.com/w3c/csswg-test/blob/db05b52e31d3f33ffc57d51d3df4a1bd0d7fb098/css-animations-1/animationevent-types.html))

I believe I also found one case where the presence of the 
`elapsedTime` member on the `AnimationEvent` prototype was being used 
to feature detect animation support but I can't find it now.

In summary, this member appears to be widely referred to although I 
have yet to find a single case where its value is actually 
consequential.

## How to define `elapsedTime` going forward

I think we have two options:

**a. The reflect-the-current-iteration approach**

Reports the ideal elapsed time such that dividing by 
`animation-duration` will give you the current iteration (ignoring the
 influence of properties like `iterationStart`). As a result, if you 
play a CSS animation forwards, then reverse it, when it plays in the 
reverse direction and fires an `animationstart` event, `elapsedTime` 
is equal to the active duration.

**b. Report the actual elapsed time of the animation for the current 
frame**

This would actually make this member more useful since it could be 
used to synchronize Javascript animations with CSS animations without 
using the Web Animations API.

It would mean changing all existing implementations, however.

I'm leaning towards specifying (a), but first I will verify that (b) 
would, in fact, mean changing all existing implementations.

-- 
GitHub Notification of comment by birtles
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/68#issuecomment-246582285 
using your GitHub account

Received on Tuesday, 13 September 2016 05:56:06 UTC