For an element with position: absolute, how does the browser decide which box is its containing block, and what do top: 0 and width: 50% then resolve against?

## The question behind the question "Positioned relative to what?" is the single most common source of surprise in CSS positioning, and the spec answers it with one concept: the **containing block**. Every box has one, and it supplies the rectangle that percentages and offsets are measured against. For an in-flow block box the containing block is simply the parent's content box. Absolute positioning is what makes the rule interesting, because it does not use the parent. ## The lookup rule For `position: absolute`, the browser walks up the ancestor chain and stops at the first ancestor that is a containing block for absolutely positioned descendants. An ancestor qualifies when either: - its `position` is anything other than `static` — `relative`, `absolute`, `fixed` or `sticky`; or - it is still static but carries a property that creates a containing block anyway: a `transform` (or the individual `translate`, `rotate`, `scale` properties), a non-`none` `filter` or `backdrop-filter`, a `perspective`, `contain: layout`, `paint`, `content` or `strict`, `will-change` naming one of those properties, or a `container-type` other than `normal`. The rectangle taken from that ancestor is its **padding box** — the border box minus borders, i.e. content plus padding. This trips people up: a wrapper with `padding: 20px` gives an `inset: 0` child a box 40px wider than the wrapper's content area, so an "overlay" laid over it covers the padding too. That is usually what you want, but it means the numbers do not match the content-box width you had in mind. If the walk reaches the root without finding a qualifying ancestor, the containing block is the **initial containing block**: a rectangle the size of the viewport, anchored at the origin of the document canvas. It is viewport-*sized* but document-*anchored*, so `top: 0` puts the element at the top of the document and it scrolls out of view like anything else. Confusing that with `position: fixed` is a classic mistake. ## What resolves against it Once the containing block is known, everything geometric on the absolutely positioned box uses it: - `top`, `right`, `bottom`, `left` and the `inset` shorthand are distances from the corresponding padding edges. - Percentage `width`, `max-width` and horizontal `padding`/`margin` resolve against the containing block's **width**; percentage `height` resolves against its **height** — which is a definite height here even if the ancestor sized itself from its content, because the ancestor's box is laid out before the out-of-flow box is positioned. - Percentage vertical padding and margins still resolve against the containing block's *width*, exactly as they do in normal flow. ```css .panel { position: relative; width: 300px; padding: 20px; /* padding box is 340px wide */ } .panel .flag { position: absolute; top: 0; left: 0; /* the padding edge, not the content edge */ width: 50%; /* 170px — half of 340px */ } ``` ## Why fixed is different — and why it sometimes isn't `position: fixed` skips the search: its containing block is the viewport, so it does not scroll. The exception is that the same containing-block-creating properties listed above — `transform`, `filter`, `contain`, `container-type` and friends — capture fixed descendants too, which is the one case where fixed elements start scrolling with the page. ## Debugging it When an absolutely positioned element lands somewhere unexpected, the diagnosis is mechanical rather than creative. Walk up from the element and ask, at each ancestor, "is this a containing block?" — check `position` first, then the exotic list. The first "yes" is your anchor. If the element flew to the top of the page, the answer was "no" all the way up and you are looking at the initial containing block. If it anchored to an ancestor you did not intend, something in between qualified — often a `transform` on an animation wrapper, or a `contain` on a component root, neither of which announces itself as positioning code. Devtools help here: computed styles show `position` per element, and inspecting the offending ancestor for `transform` or `contain` is a five-second check once you know the list exists. ## The design consequence Because the anchor is chosen by proximity, you get to place it deliberately. Put `position: relative` on the exact box you want a child to measure against — the component root for a dropdown, the figure for a caption — and the child's insets become meaningful and stable. Leaving it off and hoping is how elements end up in the page corner.