-
Notifications
You must be signed in to change notification settings - Fork 658
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-animations-2] Alternate animation composite order when owning element of A and B differs #4669
Comments
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 |
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. |
@birtles - The reference in Perhaps the coder could get away with this if their set of animations were infinite/fill-forwards... |
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 |
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. |
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). |
CSS transitions has:
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.
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 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.
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. |
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?
The text was updated successfully, but these errors were encountered: