In CSS, what does the percentage in `transform: translate(-50%, -50%)` resolve against, and why does that make it a centering idiom?

## Two different percentage bases CSS trains you to read a percentage as "a fraction of the parent". `width: 50%` is half the containing block's width. `top: 50%` on a positioned element is half the containing block's height. Even `margin-top: 10%` resolves against the containing block's *width*, not its height, which is its own famous surprise. `translate()` breaks the habit entirely. Its percentages resolve against the **element's own border box**: the X component against the element's own border-box width, the Y component against its own border-box height. `translateX(100%)` moves an element exactly its own width to the right, whatever that width happens to be. That self-reference is the entire reason the centering idiom exists. ## The idiom, step by step ```css .overlay-card { position: absolute; top: 50%; left: 50%; transform: translate(-50%, -50%); } ``` 1. `top: 50%` and `left: 50%` are resolved against the *containing block*, so the element's **top-left corner** now sits at the containing block's centre point. The element itself hangs down and to the right of centre — visibly off. 2. `translate(-50%, -50%)` is resolved against the *element*, so it slides back left by half its own width and up by half its own height. 3. The element's centre now coincides with the containing block's centre. You cannot express step 2 with `top`/`left` or with `margin`, because those percentages are relative to the parent, not to the element. The classic pre-transform version was `margin-left: -100px` with a hard-coded width — which broke the moment the content changed. The transform version is size-agnostic. ## When you still reach for it Centring a box inside a container is usually a job for the container's own alignment these days, and that material belongs elsewhere. The translate idiom earns its place where there is no cooperative parent to align against: - an absolutely positioned element pinned relative to an arbitrary anchor point, such as a tooltip whose arrow must sit on a specific coordinate - centring against a percentage position that is not 50% — `left: 33%` plus `translateX(-50%)` centres on the one-third line - a generated `::before`/`::after` badge centred on a corner - shifting an element visually without disturbing anything around it, since a transform never affects layout ## Details that catch people out **The layout box does not move.** Only the painted result shifts. The element still reserves its untransformed space, still contributes that untransformed box to the parent's sizing, and if an ancestor has `overflow: hidden`, the transformed half can be clipped even though "there is room". **Half-pixel rendering.** If the element's width or height is an odd number of CSS pixels, `-50%` lands on a half pixel. Some engines render text on a non-integer offset slightly softer. Fixing it usually means giving the element an even size rather than abandoning the technique. **Percentages are per-axis.** `translate(-50%)` with one argument sets X only; Y defaults to `0`. Writing `translate(-50%, -50%)` when you only meant a horizontal nudge is a common accidental vertical shift. **`translateZ()` rejects percentages.** The Z axis has no element dimension to resolve against, so `translateZ()` accepts only a `<length>`. `transform: translateZ(50%)` is an invalid value and the whole declaration is dropped — the transform disappears entirely rather than partially applying. The same holds for the third value of `translate3d()`. **The individual property behaves identically.** `translate: -50% -50%` — the standalone property rather than a function inside `transform` — resolves its percentages the same way against the element's own box, which makes it convenient when you want to keep a rotation or scale in `transform` untouched. **Order inside a transform list matters.** `transform: translate(-50%, -50%) rotate(10deg)` and `transform: rotate(10deg) translate(-50%, -50%)` do not land in the same place, because each function operates in the coordinate system left by the previous one — so the centring translate is normally written first.