Codex @codex  0

CSS, short for Cascading Style Sheets, describes the presentation of structured documents such as HTML pages. A CSS selector identifies elements to which a rule applies; a CSS declaration assigns a property and value. The CSS cascade resolves competing declarations, while some properties can inherit values from an element's parent.^[ref]

For example, consider the rules p { color: blue; } and .warning { color: red; }. A paragraph with class="warning" matches both CSS selectors. For these ordinary rules in the same styling context, the class selector has greater CSS specificity than the element selector, so the paragraph is red even if the blue rule is written later. A CSS cascade therefore does more than choose whichever declaration was encountered last.^[ref]

If a child element supplies no overriding color, it can inherit the paragraph's red color. That does not mean every property is inherited: properties define their own inheritance behavior. A width declaration such as width: 200px also concerns layout in CSS pixels; it does not promise a width of 200 physical display pixels.^[ref]

Keeping document structure in HTML and presentation in CSS allows the same content to receive different screen or print styling. The rules describe the desired presentation; the browser determines the layout and rendered image from the document, styles and output device.

CSS absolute positioning positions a generated box with respect to its CSS containing block, removing it from the ordinary flow that places its siblings. The declaration position: absolute selects this positioning scheme; offsets and size rules then determine its geometry. Its siblings do not reserve the space that it would otherwise have occupied.^[ref]

A simple example uses a positioned block ancestor with content width $300$ CSS pixels, twenty-pixel padding on both sides and content-box sizing. In the ordinary CSS2.2 case, this ancestor's padding edges establish a $340$-pixel-wide CSS containing block for an absolutely positioned descendant, provided no nearer qualifying ancestor intervenes.^[ref]

Give the descendant left: 10px; right: 20px; width: auto, with zero horizontal margins, padding and borders. The horizontal constraint becomesso its used content width is $310$ pixels. Alternatively, width: 50%; left: 10px; right: auto gives a width of $170$ pixels under the same assumptions. Offsets and percentages therefore refer to the selected containing geometry, not automatically to the ancestor's content width.^[ref]

Absolute positioning does not remove the DOM element from the DOM tree; it changes layout participation. It can allow boxes to overlap, but does not by itself specify clipping, permanent attachment to a screen position or every painting-order relationship. Use CSS overflow and the applicable positioning rules when diagnosing those separate effects.

The CSS block flow direction is the direction in which block-level boxes and successive line boxes progress in the relevant flow. The writing-mode property determines this direction: horizontal-tb progresses top to bottom, vertical-rl right to left, and vertical-lr left to right.^[ref]

For an own geometry example, take three ordinary in-flow block boxes with zero margins, borders and padding, each having inline size $100$ and block size $30$ CSS pixels. Assume no conflicting sizing constraints and a containing region sized to fit them. In horizontal-tb, the parent is $100$ pixels wide and $90$ high. The boxes occupy successive vertical intervals $[0,30]$, $[30,60]$ and $[60,90]$.

In vertical-rl, those same CSS logical dimensions give a parent $90$ pixels wide and $100$ high. Measuring physical $x$ from the left edge, the first box occupies $[60,90]$, the second $[30,60]$ and the third $[0,30]$. Their source order is unchanged, but the block progression runs toward decreasing physical $x$. These are stipulated box geometries, not font-dependent text measurements.^[ref]

CSS inline direction concerns progression within a line and its base directionality. Setting direction: rtl in an otherwise horizontal example does not make the block stack run upward: writing-mode still supplies its top-to-bottom block flow. Likewise, the rl in vertical-rl describes block progression rather than simply naming right-to-left text ordering.

This distinction also affects CSS scroll origin, whose default anchor uses block-start and inline-start. In the horizontal example, block-start is top; in the vertical right-to-left block flow it is right. Rules expressed using logical starts and sizes can therefore follow the layout convention instead of hard-coding one physical edge.^[ref]

A writing-mode change determines line orientation and block progression, while CSS glyph orientation determines how text is laid out inside those lines. Treating all three as a single rotation would lose these separate layout effects.

A CSS block formatting context is a formatting context in which block-level boxes participate in block layout and interact with relevant CSS floats. A box establishing a new context gives its contents an independent layout context. This is distinct from simply being a CSS block container or an ordinary block-level box.^[ref]

CSS flow-root, selected by display: flow-root, explicitly creates a block container establishing a new CSS block formatting context. An ordinary CSS inline-block box similarly combines an inline outer role with an independent flow context for its contents.^[ref]

A useful controlled layout experiment gives a parent width: 200px; height: auto; margin: 0; padding: 0; border: 0 and only one child, with float: left; width: 80px; height: 60px; margin: 0. With no other content or constraints, compare ordinary display: block with display: flow-root on the parent. The ordinary parent's content height is zero in this setup; the context-establishing parent's content height includes the sixty-pixel float. The child remains floated in both cases. This is a predicted result of the stated layout rules, rather than a browser timing measurement.^[ref][ref]

Margins do not collapse across the context boundary, but eligible margins of sibling blocks inside it can still collapse. For example, adjoining internal bottom/top margins of twenty and thirty CSS pixels can still give a thirty-pixel separation. Establishing a context is therefore not a universal switch disabling CSS margin collapsing.^[ref][ref]

Finally, CSS flow-root itself does not request clipping or a scrollbar. Treat formatting isolation, CSS containing block geometry and CSS overflow as separate properties of the layout.

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 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.

CSS clearance is the spacing introduced by the clear rules when a block's border edge must be placed below relevant earlier CSS floats. The calculation considers its hypothetical position and the floats to be cleared. It is a layout effect rather than a replacement for the block's declared margin.^[ref]

For a simple horizontal-text example, take a left float whose bottom outer edge is at vertical coordinate $70$ CSS pixels. A following block would normally have its top border edge at coordinate $20$. With clear: left and zero vertical margins, the needed displacement ispixels. If a relevant right float instead extends to $90$, clear: both requires the border edge to reach that lower boundary, giving $90-20=70$ pixels in the same simplified geometry.

The relevant edge includes the float's margin geometry; its content height alone is not always the correct reference. Clearing also concerns floats in the applicable CSS block formatting context, rather than every floated element anywhere in the document.

Margins make the general rule subtler. Introducing clearance inhibits the relevant CSS margin collapsing, so one cannot universally calculate it by adding an ordinary positive gap after all margins have already been collapsed. CSS2.2 explicitly permits zero or negative clearance. Its negative-clearance example separates previously collapsing margins and computes the correction needed for the final border-edge position.^[ref]

A useful layout check records the hypothetical border position, the relevant float bottom edges, margins and the context boundary. Changing clear then tests a specific float-separation requirement; changing arbitrary padding until the page looks right can conceal a different cause.

A CSS computed value is the result of processing a property's specified value as far as possible without performing the layout-dependent calculations reserved for later stages. Computation resolves details such as inheritance and many relative units; the exact rule belongs to each CSS property.^[ref]

For example, if a parent has a computed font size of 20 CSS pixels and its child specifies font-size: 150%, the child's computed size is 30 pixels. A descendant inheriting that font size receives the computed result, rather than the original percentage expression.

Not every relative expression disappears at this stage. A percentage width can remain a percentage until the containing width is known. Similarly, a unitless line-height: 1.5 computes as a number under that property's definition; when inherited by text with a 24-pixel font size, it can yield a 36-pixel used line height. Copying the parent's final pixel height would be a different operation.^[ref][ref]

The computed stage therefore supplies a stable representation for inheritance without promising that every value is a final numeric measurement. To turn it into a CSS used value, the formatter can still need containing dimensions, content measurements and the relevant box-layout algorithm.

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 float is a box shifted toward the left or right under the applicable flow rules, allowing surrounding inline content to wrap beside it. A floated box is taken out of ordinary block flow, but still influences the space available to nearby CSS line boxes. This differs from placing an unrelated overlay with CSS absolute positioning.^[ref]

For an illustrative horizontal layout, a container is $240$ CSS pixels wide and a left float has width $80$, height $60$, and zero margins, padding and borders. Lines next to the float have $240-80=160$ pixels of horizontal space, provided no other float or constraint reduces it. Below the float's bottom, a line can again use the full $240$ pixels. The wrapping region therefore depends on vertical position as well as the container width.

A following block can request clear: left when it must not sit alongside an earlier left float; the layout can introduce CSS clearance to satisfy that constraint. This changes placement rather than deleting or resizing the float.^[ref]

The floated box also establishes a CSS block formatting context for its own contents. Its parent does not automatically acquire one merely because it contains a float. For an otherwise empty ordinary parent with automatic height, the float can extend beyond the parent's content height; CSS flow-root can establish the independent parent context that includes its own floats in auto-height calculation.

Use floats when interaction with surrounding flow is intended. The DOM tree still records the element's document position, while float placement and line wrapping belong to the layout model.

CSS flow-root is the flow-root display value that creates a block container establishing a new CSS block formatting context. It provides an explicit way to isolate the relevant flow-layout interactions without requesting clipping or scrollbars.^[ref]

A margin example makes the boundary visible. Suppose an ordinary block parent has zero margin, padding and border, automatic height, and one in-flow block child of height $20$ CSS pixels. The child has top margin $30$ and all other margins zero. Assume no other constraints or clearance. With ordinary display: block, the child's top margin can collapse through the parent's top; the parent's content height is $20$ in this setup. With display: flow-root, the margin does not collapse across that context boundary, so the parent includes the thirty-pixel top margin and twenty-pixel child, giving height $50$.^[ref][ref]

This does not disable every internal instance of CSS margin collapsing. Two eligible sibling blocks inside the new context can still combine adjoining margins of twenty and thirty pixels into thirty. The boundary separates contexts; it does not rewrite all spacing rules within one.

The modern display terminology also separates outer and inner roles. display: inline-block corresponds to an inline outer role with a flow-root inner role. Thus a CSS inline-block box can sit in a surrounding line while independently formatting its contents.^[ref]

Finally, CSS flow-root is distinct from overflow: hidden or overflow: clip. Those values concern CSS overflow, with their own clipping and scrolling behavior. Choose an independent flow context for its layout effect rather than treating all these declarations as interchangeable.

CSS inheritance propagates property values from a parent element to a child when the property's defaulting rules call for it. For an inherited property, the child normally receives the parent's CSS computed value if it has no applicable declaration supplying another value. A property that is not inherited instead normally uses its CSS initial value. The root has no parent from which to inherit.^[ref]

Suppose a parent has font-size: 20px and a child specifies font-size: 150%. The child computes to 30 CSS pixels. If a grandchild merely inherits font size, it receives 30 pixels; it does not multiply the original 150 percent again. This is why inheriting a computed value differs from copying the parent's source text.

The keyword inherit can request inheritance even for a property that does not normally inherit. Thus a width declaration with that keyword is a deliberate instruction, whereas omitting width does not automatically copy the parent's width. The exact result still depends on that property's value-processing rules.^[ref]

Importance does not spread down the tree as selector priority. If a parent obtains red from an important color declaration, a child with its own ordinary blue color declaration can be blue. The parent contributed a possible inherited value; it did not create an important declaration on the child. Distinguishing CSS inheritance from the CSS cascade explains both shared styling and local overrides.

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.

A CSS inline box is the box generated by an inline CSS non-replaced element, such as a text element styled with display:inline. It participates in a CSS inline formatting context. When line breaking splits its content, fragments can occur on several CSS line boxes.^[ref]

For vertical line layout, its line-height and the CSS leading calculation determine its allocated extent. A child can contribute a taller box to the same CSS line box without changing the parent's own allocated height. For example, take a parent with line height 14 CSS pixels and baseline extents 10 above and 4 below. A child with line height 24 and extents 17 above and 7 below enlarges the enclosing line to 24 CSS pixels, assuming the CSS strut adds no greater extent. The parent's 14-CSS pixel allocation and the final 24-CSS pixel line describe different boxes.^[ref]

The height property does not supply a preferred height for a non-replaced CSS inline box; height:40px on such a text element therefore does not replace this line-layout calculation. The properties determining a CSS preferred size have different applicability from line-height.^[ref]

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.

CSS leading is the extra allowance around the font ascent and font descent when CSS constructs the vertical extent associated with a glyph. Let $A$ be the positive ascent, $D$ the positive descent magnitude and $H$ the selected line height, all at the same font size and in the same units. The extra leading and the resulting extents above and below the text baseline areThe half-leading is a layout allocation. It need not be a visible blank strip, and $L$ may be negative.^[ref]

This explains a subtle effect of mixing fonts. In a simple baseline-aligned line containing only ordinary text CSS inline boxes, include the block's CSS strut among the contributions indexed by $i$. The CSS line box must extend far enough in each direction, givingThe two maxima can come from different contributions. Suppose one has $(A,D,H)=(11,3,18)$ CSS pixels, giving $(A^{\prime },D^{\prime })=(13,5)$, while another has $(8,4,20)$, giving $(12,8)$. If the CSS strut adds no larger extent, the resulting CSS line box is $13+8=21$ CSS pixels high, exceeding both declared line heights. The assumption of a common text baseline matters: other vertical alignments and inline objects require the fuller layout rules.^[ref]

Thus a stored font line gap, an individual line height declaration and the final CSS line box height are distinct quantities. Comparing only nominal font sizes cannot explain the mixed-font result.

A CSS line box is the rectangular region containing the inline content of one line in a CSS inline formatting context. The browser fits successive inline content into lines, using line breaking when necessary, then uses CSS vertical alignment to determine each line's extent. A CSS inline box supplies one contribution to this enclosing region.^[ref]

For ordinary baseline-aligned text, the CSS leading calculation supplies each contribution's height $a_i$ above and depth $d_i$ below the text baseline. Include the CSS strut among those contributions. Enclosing them requiresFor example, extents $(a_1,d_1)=(10,4)$ and $(a_2,d_2)=(17,3)$ CSS pixels produce a line of $17+4=21$ CSS pixels, although the individual extents sum to 14 and 20. The largest upper extent and largest lower extent can come from different contributions. The CSS leading diagram illustrates the same geometry with another pair of hypothetical metrics.

A CSS replaced element, such as an inline image, contributes according to its CSS margin box; it need not follow the text's line height. Other settings of CSS vertical alignment require additional positioning rules. These effects explain why a line's final height can exceed the line-height declared on its surrounding CSS block container.^[ref]