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

1/n

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

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

· · Ivory for iOS · 1 · 0 · 1

@othermaciej @jensimmons

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:
drafts.csswg.org/css-cascade/#

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:
testcase.rejh.nl/webkit-animat

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.