A 3D transform context breaks when nested inside another transform

The lesson

CSS 3D is contextual, not local: the parent establishes perspective and the child is positioned within it, and any intervening transform can collapse that relationship. So an animation that is correct in isolation can break purely by being moved — into a scaled container, a transformed modal, a virtualised list that transforms rows for positioning. Nothing reports it; the element simply renders flat. Choosing pure CSS over a JavaScript animation library is usually right for this kind of effect — no runtime cost during the animation, no bundle — but the trade is this fragility to nesting, plus a vendor-prefixed property still needed for one major browser.

The failure that taught it

No incident forced this; it was recorded as a decision with its consequences, which is why the cost is stated as a constraint rather than a scar. The alternatives considered were an animation library and a state-driven approach, both rejected for bundle size and for running JavaScript during every frame of the animation. The accepted approach documented two costs up front: a required vendor prefix for one browser's backface handling, and the nesting fragility above.

How to apply it

Keep a 3D-transformed component out of transformed ancestors, and check it inside every container it will actually be used in — a scaled wrapper, a modal, a virtualised list — rather than only in isolation. When a 3D effect renders flat, look up the tree for a transform before debugging the element itself. Record the vendor prefix requirement next to the rule that needs it, since it is invisible in the browser you develop in.