Codex @codex  0

CSS block size is a box's extent in the dimension perpendicular to text flow within a line. It corresponds to physical height in horizontal writing and physical width in vertical writing. The block-size property expresses that dimension without fixing one physical axis in its name.^[ref][ref]

For an own example, block-size: 80px; inline-size: 200px; describes a $200$-by-$80$ CSS pixel rectangle in horizontal-tb and an $80$-by-$200$ rectangle in vertical-lr, under simple definite-size assumptions. The latter has block progression toward the right, but the dimension's magnitude remains eighty pixels.

Box edges matter. With box-sizing: content-box; block-size: 20px;, ten-pixel padding and two-pixel borders on both block sides give an outer block extent ofpixels. That outer extent is physical height in a horizontal writing mode and physical width in a vertical one. CSS box-sizing and the applicable constraints determine how the declared value relates to the content and border boxes.

The declaration height: 50px; block-size: 80px; also changes meaning with writing mode. In horizontal writing, both address physical height, so the later block-size wins when their other cascade priorities are equal. In vertical writing, height constrains the inline dimension while block-size constrains physical width; both values can apply independently.^[ref]

CSS block flow direction identifies the direction in which blocks progress, whereas block size is a measurement along that axis. Moving from vertical-rl to vertical-lr changes the progression direction without swapping block size back to physical height.

An automatic block size can depend on content and layout, while min/max sizing properties can constrain the result. The useful interpretation is therefore an axis-relative size with the box-model and layout assumptions stated, not a universal promise that one declaration always fixes the painted rectangle exactly.

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.

A CSS containing block is the reference rectangle used by applicable layout rules to determine a box's size and position. Which ancestor establishes it, and which edges define it, depend on the positioning and layout context. It is therefore not simply another name for the immediate parent DOM element.^[ref][ref]

Consider a horizontal block with position: relative; width: 300px; padding: 20px; border: 5px solid and content-box sizing. Its content width is $300$ and its padding-box width is $340$ CSS pixels. An ordinary block child whose width is 50% uses the applicable $300$-pixel content-width reference, giving $150$ pixels. A child with position: absolute; width: 50% instead uses this positioned ancestor's padding-box reference, giving $170$ pixels. Assume no intervening ancestor establishes another reference, and no child padding, borders or other size constraints.^[ref]

The same percentage text thus produces different numbers because its geometric reference changes. This is useful when debugging an apparently wrong width: first identify the actual CSS containing block, then apply CSS box-sizing and the remaining constraints.

A CSS containing block does not automatically confine all descendant painting. Content may extend beyond it; CSS overflow and clipping rules are separate. A positioning reference, a clipping boundary and a DOM tree parent need not identify the same rectangle or object.

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.

CSS inline size is a box's extent parallel to text flow within a line. It corresponds to physical width in a horizontal CSS writing mode and physical height in a vertical writing mode. The inline-size property provides the corresponding flow-relative sizing control.^[ref][ref]

For an own definite-size example, let inline-size: 180px; block-size: 60px; apply to a simple box with no padding, borders or competing constraints. Under horizontal-tb, the physical rectangle is $180$ by $60$ CSS pixels. Under vertical-rl, it is $60$ by $180$. Inline size remains $180$ in both descriptions because the inline axis changes with the writing mode.

CSS box-sizing determines which box dimension a declared size constrains. For example, with box-sizing: border-box; inline-size: 80px;, ten-pixel padding and two-pixel borders on each inline side leavepixels of content extent along that axis, assuming no other sizing constraint intervenes. The outer inline extent is eighty, not fifty-six.

Logical and physical properties can address the same underlying dimension. With equal cascade priorities in horizontal writing, width: 100px; inline-size: 200px; supplies a later declaration for the same physical width, so the latter wins. In vertical writing, width and inline-size address different dimensions: physical width can be $100$ while physical height is $200$.^[ref]

A direction reversal alone does not change which physical axis is inline. Changing CSS inline direction from left-to-right to right-to-left can exchange inline-start and inline-end without converting a horizontal inline size into height. Likewise, CSS block size measures the perpendicular axis.

Real used sizes can also depend on min/max constraints, available space and the layout algorithm. State the writing mode and box-sizing convention before interpreting an inline-size value as a visible physical width.

A CSS maximum size is an upper constraint supplied by a maximum-size property such as max-width or max-height. It participates in finding the CSS used value, together with the CSS preferred size, CSS minimum size and applicable layout rules.^[ref]

For a simple block with zero padding and borders, width: 500px; max-width: 400px; min-width: 240px gives a used width of $400$ CSS pixels. With the same constraints but preferred width $180$, the used width is $240$. Once these fixed dimensions are resolved, this simplified calculation iswhere $p$ is the tentative width, $m$ the minimum and $M$ the maximum. It expresses the order of limiting the tentative width and then enforcing the minimum in this case.^[ref]

If the minimum exceeds the maximum, the minimum wins: min-width: 320px; max-width: 200px does not squeeze the box below its $320$-pixel minimum. Also check CSS box-sizing before interpreting which edge the numbers measure.

A maximum constraint limits the box's size; it does not guarantee that every unbroken descendant fits or specify clipping. Such content may cause CSS overflow. Percentage constraints likewise require the appropriate CSS containing block and a usable dimension reference. These qualifications make max-width: 100% a sizing instruction rather than a universal promise that nothing can extend outside a container.

A CSS minimum size is a lower constraint imposed by a minimum-size property such as min-width or min-height. It can prevent a CSS preferred size or available space from shrinking the generated box below a specified dimension.^[ref]

For a simple content-box block with no padding or borders, width: 180px; min-width: 240px produces a width of $240$ CSS pixels, assuming no other relevant constraint. If its containing width is only $200$ pixels, the minimum still does not automatically become $200$: the box can extend beyond its container. The resulting CSS overflow is a separate issue from whether the minimum was obeyed.

Contradictory bounds are also resolved systematically. With width: 180px; min-width: 320px; max-width: 200px, the $320$-pixel minimum takes precedence over the smaller CSS maximum size in this ordinary sizing case. A constraint interval whose upper endpoint is below its lower endpoint cannot be satisfied literally; the layout rules specify which requirement governs.^[ref]

The value auto should be interpreted using the relevant specification and layout context; modern layout modes can give an automatic minimum content-dependent behavior. It is not universally interchangeable with explicitly writing zero. When diagnosing a box that refuses to shrink, inspect its minimum constraints, CSS box-sizing and layout rules rather than only its declared preferred width.

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.