How does a child with position: absolute behave inside a display: flex container — is it still a flex item?

## Out of flow means out of flex Flex layout operates on a container's **in-flow** children. `position: absolute` removes a box from normal flow, so an absolutely positioned child of a flex container is not a flex item at all. Concretely: - It contributes nothing to the main-axis free space, so `justify-content: space-between` distributes space among the remaining, in-flow children only. - `flex-grow`, `flex-shrink`, `flex-basis`, and the `flex` shorthand are inert on it — those properties only apply to flex items. - `order` does nothing, because there is no flex line to be ordered within. - It does not stretch the flex line, so it cannot make its siblings taller. This is exactly what you want for an overlay: a badge on a card, a close button in a corner, a focus ring, a dropdown anchored to a toolbar. ## The part that surprises people: the static position If every inset (`top`, `right`, `bottom`, `left`, or the logical equivalents) is `auto`, the box is placed at its **static position** — where it would have been in flow. CSS Flexbox defines that specifically: the static position of an absolutely positioned child of a flex container is determined as if it were the sole flex item in that container. So the container's alignment properties do still position it: ```css .toolbar { display: flex; justify-content: space-between; position: relative; /* makes this the containing block */ } .toolbar > .badge { position: absolute; align-self: center; /* affects the static position */ } ``` That is why a badge with no offsets can appear centred rather than pinned to the top-left corner, which looks like flex layout "still applying" — it is only the static position being computed by the alignment rules. Set any inset and that axis is resolved from the containing block instead, and the alignment contribution for that axis disappears. ## The containing block trap Offsets resolve against the box's containing block: for `position: absolute`, the **padding box of the nearest ancestor with a position other than `static`** (a transform, filter, or `container-type` can also establish one). Making an element `display: flex` does **not** make it a containing block for absolutely positioned descendants. A `.badge` with `top: 0; right: 0` inside a non-positioned flex container will pin itself to some outer ancestor — often the viewport-sized shell — and appear in the wrong corner entirely. The fix is `position: relative` on the flex container. ## Sizing when insets are set If you specify opposing insets, for example `left: 0; right: 0`, and leave `width: auto`, the box is stretched to span its containing block — the usual absolute-positioning behaviour, unchanged by the parent being a flex container. If only one inset is set, the box is shrink-to-fit sized. None of this involves `flex-basis`, which is another way of saying the flex machinery is genuinely not involved. ## A related detail worth knowing Padding on the flex container does still matter: the static position is computed inside the container's content box, and `position: absolute` offsets resolve against the containing block's **padding** box. So a container with padding places a statically positioned overlay inside the padding and an inset-positioned one at the padding edge — a small inconsistency that explains a stubborn few pixels of difference. Also note that `position: fixed` behaves the same way with respect to flex layout — out of flow, not a flex item — but its containing block is the viewport unless an ancestor has a transform, filter, or similar property that makes it the containing block for fixed descendants. ## How to answer this in an interview Lead with the categorical statement — out of flow, therefore not a flex item, therefore the flex properties and `order` do nothing. Then add the nuance that earns the point: the static position is still computed by the container's alignment properties as if the box were the sole flex item, and the containing block is the nearest positioned ancestor, not automatically the flex container. Those two facts explain nearly every real bug in this area.