@othermaciej @jensimmons

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.


@othermaciej @jensimmons

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?

Show thread

@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.

@othermaciej @jensimmons

Right, will do. Any chance you (know someone who) can point me in the right direction spec-wise?


@othermaciej @jensimmons @smfr

Hmm I found this:

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:

Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.