CSS transform generator that shows what the order costs

Yes, and it changes where the element ends up. The browser reads the list left to right and applies each function to the coordinate system the previous one left behind, which is the same as multiplying their matrices in that order — and matrix multiplication does not commute. rotate(45deg) translateX(100px) turns the element first and then slides it 100px along its own now-diagonal x-axis, landing at (70.7, 70.7); translateX(100px) rotate(45deg) slides it 100px right and spins it in place at (100, 0). The two results are 77px apart, which is why the second preview on this page exists.

They apply in a fixed order — translate, then rotate, then scale, then whatever is in transform — no matter what order you write them in the rule. That is the trade for their real advantage: each one is a separate animatable property, so a hover can scale an element while a keyframe animation independently translates it, something a single transform declaration cannot do because the second declaration wins outright. They reached all three engines in 2022 (Firefox 72, Chrome 104, Safari 14.1), and this generator will only offer the rewrite when your chain already runs in that fixed order.

Because nothing has set a perspective, so you are looking at an orthographic projection with no vanishing point. Give the parent a perspective of 400 to 1200px — one vanishing point shared by all its children, which is what you want for a row of cards — or put perspective(800px) first in the element's own chain to give it a private one centered on itself. Position matters: perspective() only affects the functions written to its right, so a chain that ends with it does nothing at all.

No — translation is the one family the origin cannot touch. transform-origin sets the fixed point that rotate, scale and skew work around, and its default of 50% 50% is why an unqualified rotate() spins about the element's center. Move the origin to 0 0 and the same rotate(30deg) swings the element down and to the right instead of turning it on the spot, while translateX(40px) still moves exactly 40px. A third value is allowed as well, but only as a length: transform-origin: 50% 50% 60px is valid and 50% 50% 20% is not.

Because transform does not apply to non-replaced inline boxes, and a span or a link is one until you change its display. The fix is display: inline-block, or letting it become a flex or grid item, at which point the property starts working with no other change. The same rule catches transform-origin, perspective and transform-style, so an inline element sitting in a 3-D scene is inert in all four.

Because the element was rasterized once and then stretched, or it landed on a half-pixel boundary. A composited layer is painted at its natural size and the GPU resamples that texture, so scale(1.4) is enlarging a bitmap rather than re-rendering the glyphs — render at the final size and scale down instead, or drop will-change once the movement is over so the layer is repainted crisply. The half-pixel version is arithmetic: translateX(50%) on an element 101px wide asks for 50.5px, and rounding it costs the vertical stems their sharpness.

Because the functions are only a notation — the engine stores one 4×4 matrix and returns that. Your chain is multiplied out at parse time, so matrix(0.7071, 0.7071, -0.7071, 0.7071, 42.4264, 42.4264) is all that survives of rotate(45deg) translateX(60px), and there is no way back to the original functions because infinitely many chains produce the same product. The Resolved matrix tab on this page does the same multiplication so you can compare, and it stays silent when the chain contains a percentage, em or rem, since those need a layout the page cannot see.