Repository navigation
[css-transitions-2][css-animations-2] The event order of the cancelled transitions/animations #11064
Description
Recently, we noticed a Gecko bug about the event order of transitioncancel in Bug 1923208. Per the example this bug, we may have a case when transitioncancel and transitionrun have the same scheduled time.
The example is something like this, when we are replacing a running transition:
<script>
function run() {
target.style.marginLeft = "100px; // We start to run a transition.
setTimeout(() => {
target.style.marginLeft = "200px"; // We replace the running transition
}, 500);
}
</script>
<body onload="run()">
<div id="target" style="transition: margin-left 100s;"></div>
<body>
So basically, in Blink and Webkit, the event order when replacing the transition is:
transitioncancel, transitionrun, .transitionstart
However, in Gecko, the order is:
transitionrun, transitionstart, transitioncancel
These events have the same schedule time, and Gecko puts transitioncancel last.
Per spec, we use the following way to decide the order of them (copied from the comments in the bug):
-
If the scheduled event times are the same then the algorithm is to sort by composite order. That's going to mean we sort as follows:
If A and B’s associated animations differ by class, sort by any inter-class composite order as defined for the corresponding classes. If A and B are still not sorted, sort by any class-specific composite order defined by the common class of A and B’s associated animations. If A and B are still not sorted, sort by the position of their associated animations in the global animation list. -
Since the classes are the same ("transition"), we'll sort by the transition-specific composite order, and then we'll hit step 2 there because the cancelled transitions don't have the owning element:
Otherwise, if only one of A or B has an owning element, let the animation with an owning element sort first.
So it seems we should put the event of the cancelled transition first because it doesn't have the owning element. However, this is not what we expected because we cancel the transition first, and then create the new transition to replace the old one.
We may need to update the spec words to address the case for cancelled transition, e.g. per Brian's suggestion in this Gecko bug:
When sorting cancel events, use the owning element and transition generation from when the transition was cancelled
Also, we have the similar issue for animationcanel (in css-animations-2), and we probably need to figure out how to use animation-name for a cancelled animation.
cc @birtles
Activity
birtles commentedon Oct 30, 2024
I had a bit of a think about this. For CSS animations we sort by:
animation-namelistSo how do we handle cancel events from animations that have been cancelled? Consider a few examples of changes to
animation-namelist with regards to cancel event ordering:Case A: If we change
animation-namefroma, btoc, bwe want to ensure the cancel event forasorts before the start event forcsince that's consistent with transitions and conceptually it makes sense to cancel old animations before adding new ones.Case B: If we change
animation-namefroma, b, ctocwe would probably prefer that the cancel event forasorts before the cancel event forb. It's not very important but we need to define some order anda, bseems the most obvious one here.Case C: What if the
animation-nameis originallya, b, c, then, in a separate style change updated tob, a, cand then later updated again toc? It would probably be most consistent for the cancel event forbto the dispatched before the cancel event toasincebappeared beforeain theanimation-nameat the point when they were cancelled.Given that, I think we could sort as:
So, for example, if both A and B have been cancelled, we just sort by the old positions in the list.
If only A or B has been cancelled, the cancelled animation sorts first.
If neither A nor B have been cancelled, we sort by the positions in the current list.
birtles commentedon Oct 30, 2024
Proposed spec edits:
In CSS Transitions level 2, Animation composite order add some introductory text:
In CSS Animations level 2, Animation composite order add:
That last sentence in particular probably needs work but that's the gist anyway.
[css-transitions-2] Define order for sorting transitioncancel events
[css-animations-2] Define order for sorting animationcancel events
[css-transitions-2] Define order for sorting transitioncancel events
[css-animations-2] Define order for sorting animationcancel events
Add more wpt for events sorting.
Bug 1933281 - Add more wpt for events sorting. r=hiro
Add more wpt for events sorting.
Bug 1933281 - Add more wpt for events sorting. r=hiro
Bug 1933281 - Add more wpt for events sorting. r=hiro
Bug 1933281 - Add more wpt for events sorting. r=hiro
dbaron commentedon Jan 14, 2026
I'd like to propose an async resolution to accept the edits for this issue, at least assuming my reasoning that follows is correct. This is the one normative change in css-transitions-2 since the last publication, so the WG accepting these edits would mean, I think, that the editors are free to republish as a new WD.
astearns commentedon Jan 26, 2026
The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.
Proposed Resolution: Accept the edits for the event order of cancelled transitions/animations
astearns commentedon Feb 2, 2026
RESOLVED: Accept the edits for the event order of cancelled transitions/animations