Skip to main content

​
The problem

A keyframe that animates transform overwrites whatever transform the element already had. In Tailwind v3 that includes rotate-45, scale-110 and -translate-y-1, so adding a motion class could silently delete a layout decision:
Nothing errored. The card simply stopped being tilted, and the cause was three files away.

​
The fix

CSS has individual translate, scale and rotate properties. They compose with transform rather than replacing it: the browser applies translate, then rotate, then scale, then whatever transform says. TailMotion ships 77 keyframes. 13 of them touch only opacity, filter, colour or clip-path and never had a transform to conflict with. Of the 64 that move an element, 32 now animate the individual properties:
That covers every entrance, every exit, every presence class, every scroll class and every stagger keyframe — the ones most likely to land on an element Tailwind has already transformed.
Every class in these families composes: tm-slide-block-start · tm-slide-block-end · tm-slide-inline-start · tm-slide-inline-end · tm-slide-block-out · tm-slide-inline-out · tm-scale-in · tm-scale-out · tm-pop · tm-zoom-in · tm-zoom-out · tm-drop-in · tm-rotate-in · tm-elastic · tm-reveal · tm-glide · tm-glide-right · tm-scale-fade · tm-rise · tm-pulse · tm-spin · tm-float · tm-drift · tm-shake · tm-wiggle · tm-bounce · every tm-presence-* · every tm-scroll-* · tm-stagger Browser support for individual transform properties is Chrome 104, Safari 14.1, Firefox 72 — older than most of the library’s other requirements.

​
The 32 that did not move

These still write transform, and are documented rather than converted, because converting them would change the motion. If one of these lands on an element you have transformed with Tailwind, wrap it:

​
Stacking two keyframe classes

Two keyframe classes on one element do not both run. Whichever comes later in the stylesheet wins animation-name; the other is discarded. That is a property of CSS animations, not of this library, and no amount of transform safety changes it.
Use a wrapper when you genuinely need two:
Or pick the class that already does both — tm-scale-in and tm-pop fade and scale, tm-slide-* fades and travels. Most requests for “fade plus slide” are already one class.
Interaction and presence classes are transitions, not keyframes, so they do stack on one element. tm-press and tm-hover-lift together are fine, as is tm-press on an element that also carries a tm-presence-* class — they transition different properties.

​
What this does not claim

TailMotion does not claim arbitrary keyframe composition, because CSS does not provide it. What it claims, and what is verified:
  • A motion class can be added to a Tailwind-transformed element without silently removing the intended transform — for the 32 keyframes listed above and every transition-based class.
  • The 32 that still overwrite transform are named, grouped by reason, and have a documented wrapper workaround.
  • Two keyframe classes on one element is documented as unsupported rather than quietly producing one of them.