[web-animations-1] Clarify when to apply animation effect

[cdoublev]

Please forgive me (and tell me) if you think that other places like StackOverflow would have been more suited to ask the following. To be honest, I don't really need to have anything clarified in the specification. I'm just trying to figure out which part of the specification the current browser behaviors are based on, to decide when to apply or remove the effect of an animation declared using the programming interface.

If it is intentional not to specify it precisely, you can avoid reading all of the following and eventually explain me why.

Below are examples of the current (unexpected?) behaviors in Chrome and Firefox.

target.style.opacity = 0.5
const effect = new KeyframeEffect(target, { opacity: [0, 1] }, 100)
const animation = new Animation(effect)

animation.play()
console.log(animation.currentTime) // 0
console.log(getComputedStyle(target).opacity) // 0

animation.play()
animation.cancel()
console.log(animation.currentTime) // null
console.log(getComputedStyle(target).opacity) // 0.5

animation.reverse()
console.log(animation.currentTime) // 100
console.log(getComputedStyle(target).opacity) // 0.5 (instead of 1?)
animation.finished.then(() => animation.playbackRate = 1)

animation.play()
animation.finish()
console.log(animation.currentTime) // 100
console.log(getComputedStyle(target).opacity) // 0.5 in Firefox (instead of 1, as in Chrome?)

In the introduction of the animation model, it is stated that an animation effect has zero or more associated properties that it affects in response to changes to its timing output. This is the only statement I can find that tells me when to apply effects. I guess they are removed when applying effects in the after phase.

I interpret it this way: effects are either applied when a procedure to control the playback changes a time value used for the timing output (including effect.updateTiming() and setting animation.currentTime or animation.startTime), or as part of the procedure to update animations and send events. If I'm not mistaken, the event loop model defines that the procedure to update animations and send events is run after (macro and micro) tasks such as console.log().

EDIT: the behavior of console.log() is not specified and it may be asynchronous, but I checked the results in the above code by assigning the value to a variable before passing it to console.log.

When running play() or cancel(), effect seems to be applied/removed before the procedure to update animations and send events, immediately after running the corresponding method.

When running finish() or reverse() (except in Chrome only if play() is run before), effect seems to be applied with the procedure to update animations and send events.

[birtles]

I think the section you're looking for is 6.13. Model liveness. Does that seem right?

Regarding the last two examples, bear in mind that when the animation is at currentTime = 100 its active time is unresolved (due to the end-exclusive timing model and the fact that the animation direction is forwards). Hence the opacity should be 0.5.

[cdoublev]

Oh, absolutely. I should apologize. I'm implementing the specification in a custom library that uses rAF internally and I was not sure that I had to trigger it + apply effects in all those parts of the animation model. I guess that Chrome returning 1 for the last example may also be explained by the third non-normative section of this chapter. Anyway, thank you again!

[birtles]

No problem! Good luck with the library!

As for Chrome returning 1 when currentTime is 100, that seems like a bug we should have a web-platform-test for. (The value returned by computedStyle should be independent of any off-main-thread rendering.)