In CSS Flexbox, what happens to a child's display, float and vertical-align once its parent becomes a flex container?

## Flex items get a new box type When an element becomes a flex container, each of its direct children that generates a box becomes a flex item — and the item's own display type is **blockified**. Blockification means the computed value of `display` is coerced to its block-level equivalent: - `inline` becomes `block` - `inline-block` becomes `block` - `inline-flex` becomes `flex` - `inline-grid` becomes `grid` - `inline-table` becomes `table` This is a computed-value change, so devtools will show you `block` even though your stylesheet says `inline-block`. Nothing about the element's *content* changes — text inside it still lays out inline, as it always did. Only the item's participation as a box has changed. ## What stops working, and why Once a child is a blockified flex item, the properties that exist only to position boxes in normal flow or in a line box become meaningless, and the specification says so explicitly: - **`float` and `clear` have no effect.** A flex item is placed by the flex algorithm; it is not taken out of flow and there is no line box for it to float against. `float: left` on a flex item is dead code. - **`vertical-align` has no effect.** It aligns inline-level boxes within a line box, and a flex item is neither. Cross-axis alignment is what replaces it. - **Margins do not collapse.** Flex items live in a flex formatting context, so adjacent margins are not merged and a child's margin never escapes through the container's edge. Two stacked items with `margin: 20px 0` sit `40px` apart, not `20px` — one of the pleasant differences from block layout, and one of the first things to check when a converted layout suddenly has more spacing than before. ```css .row { display: flex; } .row > span { float: left; /* ignored */ vertical-align: middle; /* ignored */ display: inline-block; /* computes to block */ } ``` ## The whitespace gaps that vanish A layout built from `inline-block` boxes has a famous quirk: newlines between the elements in the markup render as spaces, producing gaps nobody asked for. Switch the parent to `display: flex` and those gaps disappear. The reason is a rule about what becomes an item. A run of text directly inside a flex container is wrapped in an **anonymous flex item** — except when the run is entirely whitespace, in which case no item is generated at all. Combined with blockification, which takes the children out of any line box, there is simply nothing left for inter-word spacing to apply to. The flip side is worth knowing: non-whitespace bare text *does* become an anonymous flex item. It participates in the layout, taking a slot on the main axis, but it has no element, so you cannot select it, give it a class, or set `flex` on it. If a stray label appears to be shoving your buttons around, unwrapped text in the container is a likely culprit, and the fix is to wrap it in an element. ## Children that are not items Two display values behave specially: - **`display: none`** generates no box at all, so the child is neither an item nor anything else. - **`display: contents`** generates no box for the element itself, and its *children* become the flex items instead. This is occasionally useful for flattening a wrapper without changing the markup, but it also means the wrapper's own styling has nowhere to land. ## Why interviewers ask this It separates people who have memorised a few property names from people who understand that Flexbox replaces the layout mode of the children rather than layering something on top of it. The strongest version of the answer states the general rule — becoming a flex item blockifies the child and switches off flow- and inline-specific properties — and then derives the individual facts from it, instead of reciting a list. If you can go on to explain the vanishing whitespace gaps from the anonymous-item rule, you have shown you understand where flex items come from as well as how they behave. ## Practical consequences When migrating an old float- or inline-block-based layout to Flexbox, the leftover `float`, `clear` and `vertical-align` declarations on the children are not harmful, but they are misleading: a future reader cannot tell whether they matter. Delete them with the migration. Conversely, if someone later removes `display: flex` from the parent — behind a media query, say — every one of those dormant declarations wakes up at once, and the layout collapses in a way that looks unrelated to the change that caused it.