CSS 3D transforms and why mine kept looking flat

There's a folder on my laptop called cube-test-2. There is no cube-test-1, because I deleted that one, which tells you roughly how the first attempt went.

For about two years I had a quiet policy of not using 3D transforms. I never decided that in so many words. It was more that I'd try something, get a result that looked like a squashed rectangle rather than a rotated card, poke at it for twenty minutes, and then locate a reason the design was better flat. I got quite good at that second part. In one review I argued that a flip animation would "distract from the content", which was true in the way most things are true if you say them with enough conviction.

What got me past it was building a playground with a slider on every property, which I'll come back to. The short version is that CSS 3D is four properties and none of them are conceptually difficult. The problem is that when one of them is wrong, nothing tells you. No error, no console warning, nothing underlined in red. You get a flat rectangle and a slowly growing suspicion that you're bad at CSS.

Perspective is the part that actually creates depth

This was most of my problem and I suspect it's most of everyone's.

If you rotate an element and there's no perspective set anywhere, the browser still rotates it. It just runs the math with no depth in it. Nothing comes closer, nothing recedes, so a rotated square reads as a square that's been stepped on.

The standard explanation is that perspective works like a camera lens. I'll use it because it's close enough, although it annoyed me the first time I read it, since I know nothing about cameras and it explained one thing I didn't understand using another thing I didn't understand. What helped more was thinking of it as how far away you're standing. Up close the effect is aggressive. From across the room it barely registers.

Values I come back to, roughly:

800px to 1200px for anything that needs to look like ordinary interface work
Around 250px when you want it obviously, almost uncomfortably distorted
Past 2000px you may as well not have bothered

The thing that caught me out is that perspective normally goes on the parent, not on the element doing the rotating. On the parent it's a single shared vantage point for everything inside, which is what you want for a cube, or for a row of cards that tilt together. Set it on each child instead and every element gets its own, and the result looks subtly wrong in a way I still can't articulate properly. There's also a perspective() function you can use inside transform on the element itself, for the cases where you do want that.

preserve-3d, and an evening I'm still annoyed about

Elements flatten their children into their own plane by default. That's correct for normal layout and completely useless the moment you want six faces sitting in actual space, which is the job transform-style: preserve-3d does.

Then there's the part that got me. A handful of very ordinary properties switch preserve-3d back off on the element you've just set it on:

overflow, if it's anything other than visible
filter, including a 1px blur you added weeks ago and forgot about
opacity below 1
clip-path and mask

Mine was overflow: hidden, sitting on a wrapper because a rounded corner was clipping badly on hover. Nothing to do with the 3D at all. I spent something like three hours that night rewriting rotation values, then rewriting them back, then opening a codepen to check whether I'd fundamentally misunderstood how degrees work. The rotation had been correct the entire time.

I looked it up afterwards and found it's specified behaviour rather than a browser quirk, which somehow made me feel worse rather than better.

The order of your transforms changes the result

This one is genuinely counterintuitive and I've stopped feeling bad about it.

Transforms apply left to right, and each one carries the coordinate system with it. So rotateY(45deg) translateZ(100px) and translateZ(100px) rotateY(45deg) put the element in two different places. Identical numbers, different outcome.

Someone once described it to me as moving the room rather than moving the object. I nodded and then didn't understand it for another week. When it did land it landed all at once: rotate first, and "forward" is now pointing somewhere new, so every translate after that follows the new forward.

Which is the whole cube, really. Each face is rotated to point outward and then pushed forward by half the cube's width. Six faces, one instruction, six different directions, entirely because the rotation happened first.

Three questions I got asked in the same week

I put the playground in a group chat with two other devs and got back some version of the same three things, so they may as well go here.

Why does my CSS 3D transform look flat?

Nearly always a missing perspective on the parent, or something on that parent has quietly cancelled preserve-3d. Check overflow before you check your maths.

Does perspective go on the parent or the child?

Parent, almost always. One shared vantage point for everything inside it. The perspective() function inside a transform is for when you want one element to have its own, which comes up less often than you'd expect.

Do I need preserve-3d for a simple rotation?

No, and it's worth saying clearly because I overcomplicated a lot of straightforward hover effects before I understood it. If you're rotating a single element and there's nothing 3D inside it, perspective on the parent is the entire requirement.

backface-visibility

You can see the back of an element by default, and it renders mirrored. On a cube that means the far faces bleed through the near ones and the whole thing looks faintly haunted. backface-visibility: hidden hides an element once it has turned away from you.

It's also the entire mechanism behind flip cards. Two elements stacked, one pre-rotated 180 degrees, both with hidden backfaces, and then you rotate the parent. I had been building those with a JavaScript state toggle and two crossfading opacity transitions. For a long time.

The playground

I'd read perfectly reasonable articles about all of this. MDN is good. Everything I read was accurate and none of it gave me any intuition, which I don't think is anyone's fault. Some things you have to move with your hands.

So: the CSS 3D cube playground. Sliders on perspective, rotation, translation and transform-origin, and it writes out the CSS as you drag so you can take values straight from it. Pull perspective from 1500 down to 200 and watch the distortion arrive. Switch preserve-3d off and watch six faces drop into a stack of squares.

Ten minutes of that did more for me than everything I'd read beforehand.

Where I use this now

Not that often, honestly.

Flip cards, where there's a real front and back
A small tilt on hover, subtle enough that nobody consciously registers it
Product and gallery views, where the depth is carrying some actual meaning
Landing pages

It's a poor fit for anything people do forty times a day. A confirmation dialog that rotates into view is charming the first time and mildly irritating by the fifth, and you're rarely around to watch the fifth.

Performance is mostly a non-issue, for what it's worth. Transforms are handed to the GPU and don't trigger layout, which puts them well ahead of animating width or top. Animating perspective itself is the expensive one, so animate the transform instead.

The thing I'd treat as more than a checkbox is prefers-reduced-motion. 3D rotation is one of the more reliable triggers for people who get motion sick from interfaces, and "it's only 300ms" isn't really a defence. Put it behind the media query.

Anyway

The bit I keep turning over isn't the cube. It's that I spent two years avoiding a feature that's been in every browser since roughly forever, purely because the failure mode was silent and I read that silence as information about myself.

Which raises the fairly uncomfortable question of what else I'm doing that with. My current suspicion is clip-path, and possibly the entirety of subgrid. I've started keeping a list.