[csswg-drafts] [css-transitions-2][css-animations-2] The event order of the cancelled transitions/animations (#11064)

BorisChiou has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-transitions-2][css-animations-2] The event order of the cancelled transitions/animations ==
Recently, we noticed a Gecko bug about the event order of `transitioncancel` in [Bug 1923208](https://bugzilla.mozilla.org/show_bug.cgi?id=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](https://drafts.csswg.org/web-animations-1/#animation-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](https://drafts.csswg.org/css-transitions-2/#animation-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`, and we probably need to figure out how to use `animation-name` for a cancelled animation.

cc @birtles 

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11064 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 22 October 2024 02:36:58 UTC