[css-animations-2] Alternate animation composite order when owning element of A and B differs

[flackr]

TLDR; Can/should we change CSS Animations and CSS Transitions composite order when owning elements differ to be sorted by creation order first?

css-animations-2 and css-transitions-2 state when the owning element of A and B differs, the animations are sorted by tree order. As far as I can tell the only time this inter-element sorting is noticeable is when returning animations from getAnimations, as animation composition behaviors only applies when animations are on the same element.

It seems that it might be more consistent (and possibly more efficient) to return animations ordered by creation (i.e. position in the global animation list). We would still need to spec that animations would be sorted by tree order when multiple animations are created at the same time. Then, the first level of sorting would be more consistent with web animations, and for implementations which maintain a global animation list it would eliminate the need for a tree traversal comparison sort, e.g. WebKit, Blink (We would need to do the same).

In practice, this means for the test Order of CSS Animations - across elements the order after appending 1 and 4 would be 2, 3, 1, 4.

It's possible there's reasons why this doesn't work, but as far as I can tell this seems simpler (more consistent with web animations, easier to implement) and does not change the visible effect, whereas the tree order is inconsistent and imposes either sorting or a data structure tracking DOM changes.

@stephenmcgruer @kevers-google @graouts @birtles, thoughts?

[birtles]

I think the difficulty is that creation order is not defined for CSS animations/transitions. Not only is the timing of style updates not defined (as CSS transitions points out) leading to potential differences due to differences in batching of updates, even when the timing is the same, I don't believe there is any requirement on UAs to create the animations/transitions in any particular order (thus allowing them to process subtrees in parallel etc.).

Unfortunately I think the order of getAnimations is pretty important (since authors will almost certainly do things like document.getAnimations()[2]) so I think those differences are significant.

[birtles]

We would still need to spec that animations would be sorted by tree order when multiple animations are created at the same time.

Sorry, I totally missed this comment. I'd have to check how practical this is in Gecko (which processes style updates in subtrees in parallel) but I suspect it would be do-able.

It still leaves the issue of potential differences in the timing for style updates, however.

[egirard]

@birtles - The reference in document.getAnimations()[2] seems fairly flakey to begin with... wouldn't the reference break if/when animation 1 completes?

Perhaps the coder could get away with this if their set of animations were infinite/fill-forwards...

[birtles]

@birtles - The reference in document.getAnimations()[2] seems fairly flakey to begin with... wouldn't the reference break if/when animation 1 completes?

Yes, I agree, but even in my limited experience of working on Web compat issues, I'd say this sort of code will occur with ~100% likelihood. I write document.getAnimations()[0] pretty often and that too would be susceptible to differences in creation order in some cases.

[flackr]

Hmm, I would have thought with the existing side effects of style updates (e.g. starting transitions) browsers already need to have fairly consistent style update timing, though I'm not sure if it's specified anywhere.

[flackr]

There seems to be some expectation of when style changes occur specified in https://drafts.csswg.org/css-transitions-2/#requirements-on-pending-style-changes

When I discussed this with some style folks on blink they figured that interop incompatibilities about when style changes occurred would likely cause lots of interop issues. Maybe it's reasonable to try to achieve interop on when style changes should occur (at least with respect to developer APIs).

[birtles]

CSS transitions has:

Since this specification does not define when a style change event occurs, and thus what changes to computed values are considered simultaneous, authors should be aware that changing any of the transition properties a small amount of time after making a change that might transition can result in behavior that varies between implementations, since the changes might be considered simultaneous in some implementations but not others.

My concern is that while differences in the timing of transitions being triggered is unfortunate, unless they actually lead to a difference in the set of events being fired (which they could, but won't always), they're unlikely to cause catastrophic failure. Returning the animations in a different order, however, is more likely to.

When I discussed this with some style folks on blink they figured that interop incompatibilities about when style changes occurred would likely cause lots of interop issues. Maybe it's reasonable to try to achieve interop on when style changes should occur (at least with respect to developer APIs).

Yes, that sounds good. I'm a little unsure how practical it is, though, since we'd need to define whether each DOM API flushes style and under what circumstances. We do that for some Web Animations APIs but most specs don't.

[flackr]

CSS transitions has:

Since this specification does not define when a style change event occurs, and thus what changes to computed values are considered simultaneous, authors should be aware that changing any of the transition properties a small amount of time after making a change that might transition can result in behavior that varies between implementations, since the changes might be considered simultaneous in some implementations but not others.

My concern is that while differences in the timing of transitions being triggered is unfortunate, unless they actually lead to a difference in the set of events being fired (which they could, but won't always), they're unlikely to cause catastrophic failure. Returning the animations in a different order, however, is more likely to.

I see, tree order gives you eventual consistency (assuming the same set of eventually running animations) so as long as you retrieve an animation after they are all guaranteed to be running it will be consistent.

When I discussed this with some style folks on blink they figured that interop incompatibilities about when style changes occurred would likely cause lots of interop issues. Maybe it's reasonable to try to achieve interop on when style changes should occur (at least with respect to developer APIs).

Yes, that sounds good. I'm a little unsure how practical it is, though, since we'd need to define whether each DOM API flushes style and under what circumstances. We do that for some Web Animations APIs but most specs don't.

I'm not convinced that outside of toy cases (where the two strategies will yield interoperable lists) it will be practical to assume a static index for specific animations (given animations / transitions may start, css files load, etc), however I agree we should have a consistent ordering and tree ordering does sound like it may be consistent a bit more often than creation time.

[birtles]

I'm not convinced that outside of toy cases (where the two strategies will yield interoperable lists) it will be practical to assume a static index for specific animations (given animations / transitions may start, css files load, etc), however I agree we should have a consistent ordering and tree ordering does sound like it may be consistent a bit more often than creation time.

Yes, I agree with that summary. I'm prepared to reconsider the current behavior if other vendors / spec folks agree, but I think that summary captures why things are the way they currently are.