You inherit a stylesheet whose page grid is built from floated columns and clearfix rows. Why did float-based layout lose to flex and grid, and what would you check before converting it?

seniorshould knowfreq 34%

answer

float solves one problem: inline wrap
clearfix boilerplate on every row
no gap, no stretch, no reorder
percentage rounding drops a column
keep the floats that wrap text

basics

~20 s

Float was designed for wrapping text around an image, not for columns, so float grids need width maths, containment hacks, and source-order tricks, and still cannot do equal heights, gaps, or centring. Convert them to grid or flex, keeping float only where content genuinely wraps.

solid answer

~50 s

Float only ever had one job — take a box out of the block flow and let inline content run beside it — so using it for columns meant simulating a layout system out of side effects. You needed explicit percentage widths that had to sum correctly, box-sizing: border-box or margin gutters instead of a real gap, a clearfix on every row because the container would not measure its floats, and source order fixed to visual order. Equal-height columns, vertical centring, and distributing leftover space were simply not available, and a rounding error made a column drop below the row at one viewport width. Flex and grid solve all of that directly. When converting, I check what each float is actually doing: a row of columns becomes grid-template-columns plus gap, the clearfix rules get deleted, and any float that exists so text wraps around an image stays exactly as it is, because no other layout mode reproduces that wrap.

Float only ever had one job — take a box out of the block flow and let inline content run beside it — so using it for columns meant simulating a layout system out of side effects. You needed explicit percentage widths that had to sum correctly, `box-sizing: border-box` or margin gutters instead of a real `gap`, a clearfix on every row because the container would not measure its floats, and source order fixed to visual order. Equal-height columns, vertical centring, and distributing leftover space were simply not available, and a rounding error made a column drop below the row at one viewport width. Flex and grid solve all of that directly. When converting, I check what each float is actually doing: a row of columns becomes `grid-template-columns` plus `gap`, the clearfix rules get deleted, and any float that exists so text wraps around an image stays exactly as it is, because no other layout mode reproduces that wrap.

code

css · 8 lines

css

.row::after { content: ""; display: block; clear: both; }
.col { float: left; width: 33.333%; padding: 0 1rem; }

.row-converted {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 2rem;
}

go deeper

for a junior

Be able to say that floats were how columns were built before flexbox and grid, and that new layouts should use those instead.

for a middle

Name the concrete gaps you have to work around in a float grid — containment, width arithmetic, gutters, equal heights — and how flex or grid supplies each one directly.

for a senior

Show a migration plan: classify each float as structural or wrapping, convert rows to grid with gap, delete the containment hacks, and verify nothing depended on blockification or on the old source order.

for a principal

Own the sequencing and risk — whether to migrate incrementally behind the existing class names or in one sweep, how to keep the two systems from coexisting for years, and what visual-regression coverage makes it safe.

Float was never a layout system

float exists so a magazine image can sit at the edge of a column with text running beside it. Everything else it was used for between roughly 2005 and 2015 was borrowed behaviour: put boxes side by side by floating them all in the same direction, then repair the consequences. Knowing which consequences is what an interviewer is testing when they ask why floats are legacy.

The specific failures

Containment. A row of floats has no in-flow children, so the row collapses to zero height. Every float grid therefore ships a clearfix or an overflow hack on every row — boilerplate whose only purpose is to undo the layout method.

Width arithmetic. Columns need explicit widths that add up. With the default content-box sizing, adding padding or a border to a column pushes the total over 100% and the last column drops. Percentage widths also round, and a fraction of a pixel at one specific window width is enough to trigger the drop — the layout fails at a width nobody tested.

No gap. Gutters come from margins or padding, which means the first and last columns need special-cased rules, or a negative-margin wrapper trick. gap in flex and grid removes the whole category.

No equal heights. Floats size to their own content. Matching column heights required faux-column background images, huge padding with matching negative margins, or JavaScript. Flexbox's default align-items: stretch does it with no declaration at all.

No alignment. There is no way to centre a float vertically, and horizontal centring of a float row means more margin arithmetic. justify-content and align-items did not exist for it.

Source order is visual order. A float grid can only be reordered by editing the markup, which couples the document's reading order to the design. Flex order and grid line placement decouple them — though the accessible reading order still comes from the DOM.

Fragility under content. One taller column traps the next float against it, producing the staircase effect where a column drops and slides right instead of starting a clean new row.

What legitimately survives

Float is not deprecated, and one use has no replacement:

css

figure.inline-art {
  float: right;
  width: 18rem;
  margin: 0 0 1rem 1rem;
  shape-outside: circle(50%);
}

Text wrapping around an image or an irregular shape is inline-level behaviour. Flex and grid place boxes; neither can make paragraph lines shorten around a sibling. Drop-cap and pull-quote patterns are the same case. If a float is doing that, leave it.

How I approach the conversion

Classify every float. Is it structural (a column, a row of cards, a header/nav split) or is it a genuine wrap? Only the structural ones move.
Convert rows top-down. A .row of .col floats becomes display: grid; grid-template-columns: repeat(3, 1fr); gap: …, or display: flex when the children should size from content. Percentage widths, gutter margins, and first/last-child overrides delete along with the floats.
Delete the containment rules. The clearfix ::after and any overflow: hidden that existed purely to contain floats go with them — and removing a stray overflow: hidden may itself fix an unrelated clipped-dropdown bug.
Watch for blockification dependants. A floated <span> or <a> was blockified by the float; once it becomes a flex item it is blockified again, but an element that stops being either can silently lose its width and height.
Watch for surviving clear. A clear: both that referred to floats you removed is now dead code; one that refers to a wrap float you kept is still load-bearing.
Check reading order. If the old layout used source order to achieve a visual arrangement, confirm the DOM order still makes sense before you start reordering with grid placement.

The interview answer in one breath

"Float puts a box at one edge and lets inline content run beside it — that is all it does. Column layouts built on it needed width maths, gutter margins, a clearfix per row, and gave up equal heights, vertical alignment, gaps and reordering. Grid and flex provide those as primitives. I convert the structural floats and keep the ones that exist so text wraps."

## Float was never a layout system `float` exists so a magazine image can sit at the edge of a column with text running beside it. Everything else it was used for between roughly 2005 and 2015 was borrowed behaviour: put boxes side by side by floating them all in the same direction, then repair the consequences. Knowing *which* consequences is what an interviewer is testing when they ask why floats are legacy. ## The specific failures **Containment.** A row of floats has no in-flow children, so the row collapses to zero height. Every float grid therefore ships a clearfix or an `overflow` hack on every row — boilerplate whose only purpose is to undo the layout method. **Width arithmetic.** Columns need explicit widths that add up. With the default `content-box` sizing, adding padding or a border to a column pushes the total over 100% and the last column drops. Percentage widths also round, and a fraction of a pixel at one specific window width is enough to trigger the drop — the layout fails at a width nobody tested. **No gap.** Gutters come from margins or padding, which means the first and last columns need special-cased rules, or a negative-margin wrapper trick. `gap` in flex and grid removes the whole category. **No equal heights.** Floats size to their own content. Matching column heights required faux-column background images, huge padding with matching negative margins, or JavaScript. Flexbox's default `align-items: stretch` does it with no declaration at all. **No alignment.** There is no way to centre a float vertically, and horizontal centring of a float row means more margin arithmetic. `justify-content` and `align-items` did not exist for it. **Source order is visual order.** A float grid can only be reordered by editing the markup, which couples the document's reading order to the design. Flex `order` and grid line placement decouple them — though the accessible reading order still comes from the DOM. **Fragility under content.** One taller column traps the next float against it, producing the staircase effect where a column drops and slides right instead of starting a clean new row. ## What legitimately survives Float is not deprecated, and one use has no replacement: ```css figure.inline-art { float: right; width: 18rem; margin: 0 0 1rem 1rem; shape-outside: circle(50%); } ``` Text wrapping around an image or an irregular shape is inline-level behaviour. Flex and grid place *boxes*; neither can make paragraph lines shorten around a sibling. Drop-cap and pull-quote patterns are the same case. If a float is doing that, leave it. ## How I approach the conversion 1. **Classify every float.** Is it structural (a column, a row of cards, a header/nav split) or is it a genuine wrap? Only the structural ones move. 2. **Convert rows top-down.** A `.row` of `.col` floats becomes `display: grid; grid-template-columns: repeat(3, 1fr); gap: …`, or `display: flex` when the children should size from content. Percentage widths, gutter margins, and first/last-child overrides delete along with the floats. 3. **Delete the containment rules.** The clearfix `::after` and any `overflow: hidden` that existed purely to contain floats go with them — and removing a stray `overflow: hidden` may itself fix an unrelated clipped-dropdown bug. 4. **Watch for blockification dependants.** A floated `<span>` or `<a>` was blockified by the float; once it becomes a flex item it is blockified again, but an element that stops being either can silently lose its `width` and `height`. 5. **Watch for surviving `clear`.** A `clear: both` that referred to floats you removed is now dead code; one that refers to a wrap float you kept is still load-bearing. 6. **Check reading order.** If the old layout used source order to achieve a visual arrangement, confirm the DOM order still makes sense before you start reordering with grid placement. ## The interview answer in one breath "Float puts a box at one edge and lets inline content run beside it — that is all it does. Column layouts built on it needed width maths, gutter margins, a clearfix per row, and gave up equal heights, vertical alignment, gaps and reordering. Grid and flex provide those as primitives. I convert the structural floats and keep the ones that exist so text wraps."

Is there anything a float can do that flex and grid cannot?
Yes — make inline content wrap around a box. Flex and grid position boxes relative to each other; they never shorten a paragraph's line boxes around a sibling. Text flowing around an image, a pull quote, or a `shape-outside` silhouette is still float-only, which is why the property is not deprecated.
A float grid's last column drops to the next line only on some screens. What is the likely cause?
The columns' total outer width exceeded the container by a hair. Percentage widths round to fractional pixels, and with `content-box` sizing any padding or border adds on top of the declared width. Floats stack only while they fit, so the overflowing one wraps below. `border-box` plus `gap`-based layout removes both causes.
When you delete a clearfix, what else should you check in the same rule set?
Whether an `overflow: hidden` on the same container was also there for containment. If it was, removing it can restore intentionally overflowing content such as dropdowns, tooltips or shadows. If something still needed containment, `display: flow-root` provides it without the clipping side effect.

saying these in an interview costs you the question

Calls float deprecated or removed from CSS
Says grid can reproduce text wrapping around an image
Blames floats for bugs that are really box-sizing arithmetic
Converts wrap floats to flex and loses the wrap
Keeps clearfix rules after the floats are gone

You inherit a stylesheet whose page grid is built from floated columns and clearfix rows. Why did float-based layout lose to flex and grid, and what would you check before converting it?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Float was never a layout system

The specific failures

What legitimately survives

How I approach the conversion

The interview answer in one breath

▾common follow-ups3 questions

▾red flags5 flags

§ context

▾related questions5 questions

▾related topics4 topics

Float was never a layout system

The specific failures

What legitimately survives

How I approach the conversion

The interview answer in one breath

answer

go deeper

context