[css-transitions-1] Clarify timing of transitionrun and transitionstart

[flackr]

If you load https://flackr.github.io/web-demos/css-transitions/event-timing.html and click the test button you can see the precise ordering of events when a transition is triggered.

Interop difference, Safari notably fires transitionrun, transitionstart before the next requestAnimationFrame, where Chrome and Firefox don't fire these events until the following frame.

Even more surprisingly though, this occurs even if you access the animation immediately calling target.getAnimations() (check the flush style checkbox). I think as a developer I would expect that if the animation is returned by getAnimations that it should fire transitionrun as part of dispatching animation events before the next raf

transitionrun says:

The transitionrun event occurs when a transition is created (i.e., when it is added to the set of running transitions).

Notably, the definition of running transitions says:

Each of these transitions also has a start time, end time, start value, end value, reversing-adjusted start value, and reversing shortening factor.

The transition may not yet have a start time if it is composited, which may be a good reason to defer transitionstart, however I think as a developer I would expect transitionrun to fire right away.

Related chromium issue: https://issues.chromium.org/394767658

[bramus]

The transition may not yet have a start time if it is composited, which may be a good reason to defer transitionstart, however I think as a developer I would expect transitionrun to fire right away.

+1 to this suggestion. transitionrun not firing immediately (in Chrome and Firefox at least) is currently an issue when building a custom style observer to respond to style changes: it fires a frame too late, potentially causing glitches as explained here.

[birtles]

If you load https://flackr.github.io/web-demos/css-transitions/event-timing.html and click the test button you can see the precise ordering of events when a transition is triggered.

Interop difference, Safari notably fires transitionrun, transitionstart before the next requestAnimationFrame, where Chrome and Firefox don't fire these events until the following frame.

I might be misunderstanding the test, but if you force a style flush, Firefox also dispatches transitionrun before the next animation frame:

I think the more precise definition of transition events is in level 2 but it could probably be clarified that that if the transition did not exist in the previous frame it should be treated as "idle" for the previous frame (or simply update the chart to say "idle or non-existent").

+1 to this suggestion. transitionrun not firing immediately (in Chrome and Firefox at least) is currently an issue when building a custom style observer to respond to style changes: it fires a frame too late, potentially causing glitches as explained here.

I think transition events are a bit of a blunt instrument for observing animation state. For example, there's no event when the user updates an animation's duration. Internally Firefox has an animation observer interface which is used by DevTools. I wonder if it might be useful to standardise something like that in future as I've wanted it a few times and it's come up in a number of other issues too, from memory.