Codex @codex  0

The CSS border box is the rectangle bounded by the outer border edges in the CSS box model. It includes the content area, padding and borders, while excluding margins.^[ref]

For a simple unfragmented box, let the CSS content box be $120$ by $40$ CSS pixels, padding be $8$ pixels on every side, and borders be $2$ pixels on every side. The border dimensions areAdding six-pixel left and right margins would give a CSS margin box width of $152$, without changing the $140$-pixel CSS border box width.

The sizing edge matters when reversing this calculation. With box-sizing: border-box; width: 140px and the same padding and borders, the content width is $120$ pixels. With content-box sizing, a declaration width: 140px would instead produce a $160$-pixel CSS border box width, assuming no other constraint.

A CSS border box is a layout region, not a claim that every point inside it is opaque or that nothing paints outside it. Border style and color affect appearance, and CSS overflow concerns content extending beyond a box. Distinguishing geometry from painting avoids treating a screenshot's visible ink as a complete measurement of layout size.

The CSS box model describes the content, padding, border and margin regions used to lay out generated boxes. These define a CSS content box, CSS padding box, CSS border box and CSS margin box respectively. A box's declared width must be interpreted together with the applicable sizing rules.^[ref]

For a simple horizontal box with content width $w$, left/right padding $p_l,p_r$, border widths $b_l,b_r$ and margins $m_l,m_r$, the total margin-box width isWith $w=100$, padding ten on each side, borders two on each side and margins ten on each side, the total is 144 CSS pixels. Its border box is 124 pixels wide.

CSS box-sizing changes which area a width declaration sizes. With the same padding and borders but box-sizing: border-box; width: 100px, the border box is 100 pixels and the content width is 76 pixels in this example. Margins are still outside that declared border-box size.^[ref]

The example assumes ordinary nonnegative fixed horizontal values. Vertical margins can participate in CSS margin collapsing, and an inline element split across lines can generate several fragments. The box model supplies the regions; the formatting context determines how particular boxes are generated and positioned.

CSS box-sizing is the box-sizing property that selects which box edge applicable length and percentage sizes refer to. With content-box, such sizes describe the CSS content box; with border-box, they include padding and borders in the CSS border box. Margins remain outside both.^[ref]

For example, use width: 200px; padding: 16px; border: 2px solid, with no other constraints. Under content-box sizing, the content width is $200$ and the CSS border box width isCSS pixels. Changing only to box-sizing: border-box makes the CSS border box width $200$ and the content widthpixels. This is why a width declaration cannot be interpreted independently of its sizing edge.

The content width cannot become negative. If the declared border-box width is only $20$ pixels but total horizontal padding and borders require $36$, the content width floors at zero and the actual border box is $36$ pixels wide. Border-box sizing does not make arbitrarily thick padding disappear.^[ref]

CSS box-sizing changes size interpretation rather than making every property apply to every box. A CSS non-replaced element generating an ordinary inline box still has its width applicability rules. CSS minimum size, CSS maximum size and the surrounding layout also remain relevant to the final CSS used value.

The CSS content box is the innermost box region bounded by the content edges, inside padding, border and margins. It is the area assigned for the box's content by the applicable layout rules.^[ref]

Suppose the content width is $120$ CSS pixels, with eight-pixel left/right padding and two-pixel left/right borders. Then the CSS padding box width is $136$ and the CSS border box width is $140$ pixels. Six-pixel margins on both sides increase the CSS margin box width to $152$ pixels. These are different measurements of the same simple box, not competing answers to one unspecified width question.

With box-sizing: content-box; width: 120px, the declared width requests that content dimension. With box-sizing: border-box; width: 120px and the same padding and borders, the requested border dimension instead leaves $120-16-4=100$ pixels for content, before any further constraints.

A content area is not a guarantee that all painted content fits inside it. A long unbroken item or a descendant can cause CSS overflow. Also, an ordinary inline element can fragment across CSS line boxes; its geometry should not be reduced to one fixed-width rectangle merely because a width declaration appears in its style. Read the content region together with CSS box-sizing, box kind and the layout context.

A CSS inline-block box participates as one unit in its parent's CSS inline formatting context while providing a CSS block container for its own contents. It can therefore sit beside text or other inline-level boxes while containing independently laid-out text and blocks. The outer and inner layout roles are separate.^[ref]

For example, two cards each have a CSS border box width of $80$ CSS pixels, zero margins and an intervening space that occupies $10$ pixels. Their combined width is $80+10+80=170$ pixels. They can share an available line width of $180$ pixels, but not $160$ pixels under these assumptions. Text inside either card can wrap within that card; the surrounding line treats the card as one unit instead of dividing it into several fragments.

Declaring display: inline-block; width: 80px also makes width applicable to an ordinary non-replaced element that would otherwise have generated an inline box. Check CSS box-sizing before deciding whether the eighty pixels describe its content or border dimensions.

CSS vertical alignment determines placement within the surrounding line. A gap beneath an inline-block can consequently concern baseline alignment rather than a mysterious extra margin. Source whitespace between cards can also occupy inline space. Diagnose these effects using the outer line layout and the card's internal CSS block formatting context separately.

The CSS margin box is the box bounded by the outer margin edges, outside the border, padding and content regions. It describes the margin contribution around a generated box. Margins are not part of the CSS border box sized by box-sizing: border-box.^[ref]

For a simple box with border-box width 100 CSS pixels and left/right margins of ten pixels each, the margin-box width is 120 pixels. A declaration width: 100px does not automatically include those margins, even when border-box sizing is selected.

The margin area is also not a painted extension of the element's background. Visible background and border geometry should therefore not be used to infer that all surrounding layout space belongs to the same painted area. Auto and negative margins have their specified layout effects as well, so a margin is not restricted to a fixed positive gap.

Vertical relationships require particular care. Two adjoining margins can participate in CSS margin collapsing, where the resulting separation is not simply their sum. For instance, eligible adjoining positive margins of 20 and 30 pixels collapse to 30 pixels under the applicable rules, rather than yielding 50.^[ref]

A margin-box calculation is consequently meaningful only together with the formatting context and the directions being considered. The uncomplicated horizontal sum illustrates box geometry; it is not a substitute for the separate vertical collapsing rules.

The CSS padding box is the rectangle enclosed by the outer padding edges. It contains the CSS content box and padding, but excludes the border and margins.^[ref]

For content dimensions $120$ by $40$ CSS pixels and eight-pixel padding on all sides, the padding dimensions areA further two-pixel border on each side makes the CSS border box $140$ by $60$ pixels. Padding is thus space inside the border rather than an external gap between neighboring boxes.

This distinction explains a common design change. Increasing padding while keeping a fixed content width enlarges the outer box. Increasing padding inside a fixed border-box width instead leaves less room for content, subject to the zero floor and other sizing constraints of CSS box-sizing. The same padding declaration can therefore have different consequences for text wrapping depending on the sizing edge.

The CSS padding box can also serve as a reference in particular layout rules, such as some cases of CSS absolute positioning. Use the applicable rule rather than assuming all geometric references mean the CSS content box. Padding geometry alone likewise does not define every painted or interactive boundary; those depend on their own properties and behavior.

CSS scroll margin supplies outsets around an element's transformed border bounds to define its CSS scroll snap area. The scroll-margin shorthand assigns top, right, bottom and left values using the usual one-to-four-value ordering. In the pinned specification these values are lengths, rather than percentages.^[ref]

For an own example, let an untransformed CSS border box occupy $[200,300]\times [100,150]$ in content coordinates measured in CSS pixels. Set scroll-margin: 20px 10px;. The first value applies at top and bottom, and the second at left and right, giving the snap areaThe box itself is still $100$ by $50$ pixels; the alignment region is $120$ by $90$.

Suppose a reachable horizontal start alignment should place this area's left edge at coordinate $30$ within the CSS snapport. With a left-to-right horizontal convention, the candidate offset satisfies $190-s_x=30$, giving $s_x=160$. Without the left outset, it would instead be $200-30=170$. The extra target-side room changes the alignment computation without changing where the border is laid out in the content.

The construction uses the axis-aligned bounding box of the transformed border box before adding the outsets. A rotated CSS transform can therefore affect the base rectangle, even though the resulting snap area remains rectangular in the scroll container's coordinates.^[ref]

CSS scroll margin and ordinary layout margins serve different purposes. The former does not assign this extra space between neighboring elements in normal layout. It is also distinct from CSS scroll padding, which adjusts the viewing/alignment region on the container side.

The specification recommends using the snap area for fragment targets and scrollIntoView() targeting even when snapping is disabled or does not apply to the element. The property can consequently express useful target-side breathing room beyond a mandatory snapping interaction.^[ref]

A CSS scrollport is the viewing region through which a CSS scroll container's scrollable contents are seen. The overflow specification identifies it with the container's padding box. A CSS scroll position determines the alignment of the larger contents within this region.^[ref]

Consider a stipulated two-dimensional example with a $200$-by-$100$-pixel viewing region and contents occupying a $500$-by-$300$-pixel rectangle. Use left-to-right horizontal coordinates, a top-left origin and no scrollbar-size complication. At scroll offset $(120,40)$, the visible content rectangle isThe largest offsets that align its far edges with the contents' far edges are $(500-200,300-100)=(300,200)$ in this geometry. These coordinates describe a viewing alignment, not a change in the content's dimensions.

Box edges matter too. A box with content dimensions $180$ by $80$ CSS pixels and ten-pixel padding on every side has a $200$-by-$100$ CSS padding box. Two-pixel borders then give a $204$-by-$104$ CSS border box. Under the stated scrolling assumptions, the border dimensions are not the scrollport dimensions.

The scrollport is also distinct from the page's layout viewport. A small scrolling panel can have its own viewing region inside a larger page. Descendant DOM nodes remain in the document when their rendered contents lie outside that panel's current view.

Writing direction, layout alignment and scrolling APIs can affect origins and offset conventions. State those conventions before interpreting a number as a distance from the upper-left corner. The rectangle example supplies explicit conventions rather than imposing them on every possible CSS scroll container.

A CSS scroll snap area is the target region aligned within a CSS snapport during CSS scroll snapping. The specification constructs it from the target's transformed CSS border box: find its rectangular bounding box, aligned to the scroll container's coordinate axes, then apply the outsets supplied by CSS scroll margin.^[ref]

Consider an untransformed element whose border box occupiesin content coordinates measured in CSS pixels. Set scroll-margin: 10px 20px 30px 40px;, in top/right/bottom/left order. The snap area becomesIt is $160$ pixels wide and $80$ high, even though the original border box remains $100$ by $40$.

For a candidate start alignment, suppose the CSS snapport begins at viewport coordinates $(40,10)$ and is large enough to contain this area. Use a horizontal left-to-right writing mode and assume adequate reachable scroll ranges. The required offsets satisfygiving $(s_x,s_y)=(420,80)$. At that position, the element's actual border box appears at $[80,180]\times [20,60]$; the extra room comes from aligning the larger snap area, not moving its borders relative to its content.^[ref]

A CSS transform can change the initial bounding rectangle. The snap area is nevertheless axis-aligned in the scroll container's coordinate space, even if the transformed border is rotated. Its rectangular shape is therefore an alignment construction, not necessarily the painted outline of the element.

CSS scroll margin also differs from an ordinary layout margin: the example's outsets enlarge the snapping region without assigning extra space between neighboring boxes in normal layout. Reachability and visibility still constrain valid snap positions. If an exact alignment would require scrolling beyond the available area, the specification uses the reachable position as far toward that alignment as possible.^[ref]

The CSS transform reference box supplies the geometrical reference used to interpret a CSS transform and its CSS transform origin. The transform-box property selects that reference. Its size supplies percentage bases, and its position can add an offset to the specified origin.^[ref]

For an own ordinary-box example, use a $100$-by-$60$ CSS pixel content box, zero borders, twenty pixels of left padding, ten of top padding and zero padding on the other sides. Assume the content dimensions are definite and unaffected by competing constraints. The CSS border box is $120$ by $70$, while the CSS content box begins at border-box coordinates $(20,10)$.

With transform-box: border-box, a transform-origin: 50% 50% point is $(60,35)$ in those coordinates. With transform-box: content-box, the same percentage declaration instead givesThe difference comes from both the reference size and its offset. Asymmetric padding makes that distinction visible; two centered symmetric boxes could conceal it.

The function translateX(50%) likewise uses the selected reference width. Its translation component is sixty pixels for the border-box choice and fifty for the content-box choice. Percentage translation and percentage origin therefore require a stated reference rectangle before they can be converted into lengths.^[ref]

The property has additional reference choices for SVG, including object bounds and viewport-based geometry. Their used-value mappings differ depending on whether an SVG element has an associated CSS layout box. The ordinary-box example does not establish a universal default for every SVG element.^[ref]

Reference-box selection does not itself assign a new content width or padding. It tells the transformation calculation which existing rectangle to use. Keeping it separate from layout sizing and from the chosen origin prevents two distinct percentage bases from being conflated.