On 2015/06/22 13:10, Shane Stephens wrote:
On Mon, Jun 1, 2015 at 2:39 PM Brian Birtles <[email protected]
Furthermore, even if we
did require that, you'd get strange results when, for example, you do
the following:
elem.style.animation = 'a 2s, b 3s';
getComputedStyle(elem).animationName; // flush style
elem.style.animation = 'a 2s, c 4s, b 3s';
let anims = elem.getAnimations(); // returns a, c, b
elem.style.animation = '';
anims.forEach(anim => anim.play());
elem.getAnimations(); // returns a, b, c. What??
This is slightly odd, but quite explainable and definitely a corner case.
I'm concerned these little oddities tend to lead to obscure bugs and I
think it would be preferable to avoid them if we can.
I wonder if we should change the animation sequence number to be based
on when the animation last transitioned out of the idle state.
If we did that, the order in the first example would be 'a, d, c, b'. In
the second example, we'd get 'a, b, c' in both cases.
Doing this would also allow authors to alter the priority of animations
without having to regenerate them: simply cancel() and play() to push to
the top of the stack.
I think this is intuitive since cancelling an animation effectively
takes it out of any composition stack it might be contributing to.
What do you think?
I'm not 100% sure that there's an issue that needs solving - these are
really edge cases and as long as the behavior is consistent I think it's
fine.
It fixes the inconsistency that a CSS animation/transition generated by
CSS markup, but then disassociated from that markup, suddenly sorts
differently based on some now opaque history of when stylesheets were
processed. Indeed, that order might even be indeterminate if there were
non-blocking stylesheet loads.
It also fixes the following weirdness:
var moveLeft = new Animation(...);
var moveRight = new Animation(...);
moveRight.play();
...
moveLeft.play();
// Wait, why doesn't moveLeft take effect?
One concern I have is that currently text order (or creation order) is
inviolate which makes it easy to reason about; but that might be
outweighed by the fact that if we made this change then authors could
(to a degree) choose to reorder the animations.
I guess the central question is whether we want authors to be able to
reorder? If yes, I think we probably want to give them something nicer
than this, and if we do then we can specify that CSS uses it to get
prioritization right.
I think it's easier to reason about (of course I would say that!). If
you're tied to CSS markup, that's where your order comes from.
Otherwise, it's based on start order. Furthermore, to move between the
two modes you have to explicitly break the link with markup and restart
the animation (hence establishing the start order) so there are no
surprises.
So I think this proposal makes the behavior more consistent and
intuitive and happens to provide a basic means for shuffling animations
without any overhead.
I guess my question is, what is the problem with the proposal? I didn't
get any feedback on this for 3 weeks so I specced it[1][2][3],
implemented it[4] and tested it[5] and in every regard it seems
preferable to me than the old behavior.
Brian
[1]
https://github.com/w3c/web-animations/compare/103c2ccb98bd...ce4e853582067
[2]https://rawgit.com/shans/csswg-drafts/animations-2/css-animations-2/Overview.html#animation-priority
[3]https://rawgit.com/shans/csswg-drafts/animations-2/css-transitions-2/Overview.html#animation-priority
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1171817
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1150810
