I think I ran into a bug today:
CSS (pseudo):
.container {
translate: 0 0;
animation: a 1s;
transition: translate 1s;
}
.container.animate {
translate: 0 -100%;
animation: a 1s;
}
\@KeyFrames a {
0% { translate: 0 0; }
100% { translate 0 100% }
}
Now, if I add the .animate class, it looks like the animation starts for 1 frame, but then gets replaced by the transition.
1/n
I was under the impression that animations should win, but I could be wrong? Chrome and Firefox behave as (I) expected (the animation runs and ignores the transition).
Should I file a bug?
@rgadellaa @jensimmons Sure file, but if possible check if the spec says what should happen in case of a transition and an animation both applying to the same element. It’s possible that we have a bug, or that Chrome and Firefox have a bug, or that the spec leaves it undefined, which would be a spec bug.
Right, will do. Any chance you (know someone who) can point me in the right direction spec-wise?
Thanks!
@othermaciej @jensimmons @smfr
Hmm I found this:
https://drafts.csswg.org/css-cascade/#cascade-sort
It states that transitions have higher priority than animations, but I think they're talking about the values of the [at]keyframes definition, not the animation when it's actually running? Those are basically transitions as well, right? Going from keyframe x to y?
I've also worked on a reduced testcase:
https://testcase.rejh.nl/webkit-animation-vs-transition/