In CSS, when you set float: left on an image, what happens to the block boxes that follow it and to the text inside them?

## "Partially out of flow" is the whole idea Every other out-of-flow mechanism in CSS is all-or-nothing: an absolutely positioned box is invisible to its surroundings, full stop. A float is the odd one. It is removed from flow *for block-level layout* and still present *for inline layout*. Hold those two halves apart and every float surprise becomes predictable. ```css img.avatar { float: left; margin-right: 1rem; } p.bio { background: #eee; } ``` ## Half one: block boxes ignore it The paragraph after the float is positioned as if the float were not in the document. Its top border edge sits where it would have sat anyway, and its background paints the full width of the containing block — **behind** the floated image. Give the paragraph a border and you will see the border line pass under the image. Nothing about the float shrinks the block box. This is also why a container of pure floats has nothing to size against, and why long-lived float layouts always came with a containment trick. ## Half two: line boxes avoid it Inside that full-width paragraph, each line box is shortened so it does not intersect the float's **margin box**. Line one starts to the right of the image and is narrower; so does line two; and the first line whose position is below the float's bottom margin edge goes back to the paragraph's full width. Rendered together, the shortened lines read as text wrapping around the image. Two consequences fall straight out of this: - The gutter between image and text is the float's own `margin-right` (`margin-left` for `float: right`). Padding on the paragraph cannot produce it, because the paragraph is full width already. - Nothing wraps "around" the bottom of the float. The wrap ends the instant the lines drop past it. ## What float does to the floated box itself - It is shifted as far to the left (or right) as it fits inside its containing block's content edge, respecting earlier floats. - Its `display` is **blockified**: `inline` computes to `block`, `inline-flex` to `flex`, `inline-grid` to `grid`. That is why a floated `<span>` suddenly honours `width` and `height`. - A float with `width: auto` shrinks to fit its content rather than filling the line, so floated boxes usually need an explicit width in layout code. ## Multiple floats Floats in the same direction stack along that edge until the remaining space is too narrow, then the next one drops to a new line below the tallest earlier float. This is the classic "float drop" or staircase effect: a single column that is one pixel too wide, or one column that is taller than the rest, and the grid falls apart at a specific viewport width. There is no equal-height behaviour and no distribution of leftover space — two of the reasons floats lost the layout job. ## Where float is simply ignored ```css .flex-parent { display: flex; } .flex-parent > img { float: left; } /* no effect */ ``` `float` does not apply to flex items or grid items — the parent's layout model owns their placement. It is also ignored on absolutely positioned and fixed-position boxes, where the computed value of `float` becomes `none`. If a float "stopped working", one of these three is usually why. ## Interview framing A strong answer names both halves in one breath — "block boxes pretend it isn't there, line boxes make room for it" — and then uses that to explain a concrete symptom: the background running under the image, the gutter coming from the float's margin, the wrap stopping at the float's bottom edge. A weak answer says only "it makes text wrap", which is the visible effect without the rule that produces it.