In CSS, an element has `box-sizing: border-box`, `width: 300px`, `padding: 16px`, `border: 1px solid`, and `margin: 24px`. How much horizontal space does it take up inside its parent, and how wide is its content box?
answer
- two numbers, not one
- painted box vs claimed space
- border-box stops at the border
- margin is the outermost layer
- 100% plus margin still overflows
basics
~20 sThe painted box is 300px because border-box includes padding and border, leaving a 266px content box (300 − 32 − 2). Margins stay outside the declared width, so the element reserves 300 + 24 + 24 = 348px of horizontal space in its parent.
solid answer
~40 sUnder `border-box`, `width: 300px` describes the border box, so the element paints exactly 300px wide and the content area is 300 − 32 padding − 2 border = **266px**. Margin is never part of `width` in either sizing model — it belongs to the outermost layer, the margin box — so horizontally the element reserves 24 + 300 + 24 = **348px** of its parent's content box. That distinction is why `width: 100%` plus any margin overflows a parent even with a `border-box` reset in place: the percentage already consumed the full containing block, and the margin has nowhere to go. The usual fixes are to move the spacing to padding on the parent, use `gap` in a flex or grid container, or write `calc(100% - 48px)`.
code
css · 8 lines.panel {
box-sizing: border-box;
width: 300px; /* painted border box */
padding: 16px; /* carved out of the 300px */
border: 1px solid #333;
margin: 24px; /* outside the 300px */
/* content box: 266px, horizontal footprint: 348px */
}go deeper
Be ready to give two numbers and label them: the painted box is 300px, the content box is 266px, and the element claims 348px of space once margins are counted. Say that margin is outside width.
Explain that box-sizing chooses between the content box and the border box only, that margin belongs to a fourth layer outside both, and compute the same example under content-box to show the difference.
Show that you reach for the structural fix rather than arithmetic: parent padding or gap instead of item margins, and reserve calc() for cases where the spacing genuinely has to live on the child.
Own the spacing convention across a codebase: deciding that components never set outer margins, and that containers own spacing through padding and gap, removes a whole class of overflow bugs before anyone has to debug one.
## The layer margin lives on The box model has four nested layers — content, padding, border, margin — and `box-sizing` chooses between only two of them as the meaning of `width`: the content box (`content-box`, the initial value) or the border box (`border-box`). **Margin is never an option.** It is the outermost layer, it is always transparent, and it describes space the element demands *from its surroundings* rather than any part of the element itself. That gives two different numbers for any element, and interviewers ask this question to see whether a candidate keeps them apart: - the **painted** width — the border box, which is what a background covers and what a border outlines; - the **footprint** — the margin box, which is what the parent's layout has to accommodate. ## Working the example ```css .panel { box-sizing: border-box; width: 300px; padding: 16px; border: 1px solid; margin: 24px; } ``` - Painted width: **300px**, because `border-box` folds padding and border into the declared value. - Content box: 300 − (16 + 16) − (1 + 1) = **266px**. Any child with `width: 100%` resolves against this 266px, not against 300px. - Horizontal footprint: 24 + 300 + 24 = **348px** of the parent's content box. Under `content-box` the same declarations would paint 300 + 32 + 2 = 334px and take a 382px footprint, with a 300px content area. ## Why this shows up as a bug The practical version is `width: 100%` plus a margin: ```css .field { width: 100%; margin: 0 12px; } /* overflows by 24px */ ``` The percentage already resolved to the containing block's full inline size, so the extra 24px of margin pushes the margin box past it, and either a scrollbar appears or a sibling gets shoved. A `border-box` reset does not help here — it absorbed padding and border, and neither of those is the culprit. The reliable fixes are to give the *parent* padding instead of giving the child margins, to use `gap` when the parent is a flex or grid container so spacing is distributed between items rather than added to them, or to state the arithmetic explicitly with `width: calc(100% - 24px)`. ## Two more properties of the margin box **Margins can be negative.** `margin-left: -8px` pulls the border box outward past its normal position and reduces the footprint accordingly — a legitimate technique for pulling an element out of a padded container, and a legitimate source of confusion when someone else's stylesheet uses it. **Vertical margins between certain boxes may combine into one** rather than adding, which means the *vertical* footprint of a stack of elements is often less than the sum of their margin boxes. That collapsing behaviour is its own rule with its own conditions; the horizontal arithmetic in this question is never affected by it. ## Auto margins `margin: 0 auto` on a block-level element with a definite width splits the leftover inline space in the containing block equally between the two sides — the standard horizontal centring idiom. It only works when there *is* leftover space, which is why it does nothing on an element that is already as wide as its containing block. ## The degenerate `border-box` case One related edge worth having ready: with `border-box`, if padding and border together exceed the declared width, the content box is floored at zero instead of going negative and the painted box grows past the declared value. `width: 100px; padding: 60px` renders 120px wide with no room for content. So `border-box` guarantees the painted width only while the inner layers fit inside it. ## How to answer Give both numbers and label them: "300px painted, 266px of content, and 348px of horizontal space claimed from the parent." Then add the one-line reason — margin is outside the border box in both sizing models — and, if there is room, the `width: 100%` plus margin overflow as the reason anyone cares.
- Why does `width: 100%` with a margin still overflow when a `border-box` reset is applied?Because the reset only folded padding and border into the declared width, and neither of those is the problem. The 100% already resolved to the containing block's entire inline size, and margin sits outside the border box, so the margin box exceeds the container. Move the spacing to the parent's padding, use `gap`, or subtract it with `calc()`.
- With `border-box`, what renders if `width: 100px` and `padding: 60px`?The used content width is floored at zero rather than going negative, so the element paints 120px wide with no content area at all. `border-box` holds its promise only while padding plus border fits inside the declared width; beyond that the border box grows and the declared value is effectively a minimum.
- Does `margin: 0 auto` centre an element under both `box-sizing` values?Yes — auto margins split the leftover inline space in the containing block, and `box-sizing` only changes how the element's own width was computed, not whether space is left over. What breaks centring is having no leftover space at all, which is why `margin: 0 auto` appears to do nothing on an element that already fills its containing block.
saying these in an interview costs you the question
- Answers 348px as the painted width
- Thinks border-box absorbs margin too
- Computes the content box as 300px under border-box
- Believes a border-box reset prevents margin overflow
- Assumes horizontal margins collapse like vertical ones