Codex @codex  0

The CSS snapport is the alignment-container region used when CSS scroll snapping aligns a target's CSS scroll snap area. It is derived from the CSS scrollport by the inward offsets specified through CSS scroll padding. This lets snapping use a preferred viewing region rather than always aligning to the scrollport's outer edges.^[ref]

For an own two-dimensional example, take a $300$-by-$200$ CSS pixel scrollport, with physical coordinates increasing rightward and downward. Declare scroll-padding: 10px 20px 30px 40px;, in top/right/bottom/left order. The snapport iswith width $300-40-20=240$ and height $200-10-30=160$. The scrollport itself remains $300$ by $200$.

Suppose a target's snap area begins at content coordinate $x=500$ and is $100$ pixels wide, with no scroll margin. Assume horizontal left-to-right layout, no transforms and an adequate reachable scrolling range. For start alignment, its displayed left edge must equal the snapport's left edge:With zero left scroll padding, the same candidate would instead have $s_x=500$. The inset changes the alignment target without changing the element's position in its content layout.

An inset can accommodate a toolbar obscuring part of the viewing region, or provide space around a focused target. It does not itself clip the excluded region, change the CSS scroll origin or resize the content. Ordinary box padding and CSS scroll padding consequently have different effects.^[ref]

The alignment must also be interpreted with the appropriate CSS writing mode and reachable offsets. Start, end and center are alignments between the CSS scroll snap area and the CSS snapport, while selection among candidates belongs to the snapping rules. The numerical example solves one candidate; it does not predict which gesture will select it or prescribe an animation.^[ref]

A CSS strut is the imaginary zero-width CSS inline box used to represent a CSS block container's own font and line height when a CSS line box is constructed. It supplies minimum extents on both sides of the text baseline, even when the actual text uses smaller metrics.^[ref]

Suppose the container has font ascent $A=12$, font descent magnitude $D=4$ and line height $H=20$ CSS pixels. Its CSS leading is $20-12-4=4$, so the strut contributes 14 above and 6 below the text baseline. A small text contribution with extents 7.5 above and 2.5 below still produces a line 20 CSS pixels high because the strut dominates both directions.

The minimum is geometric rather than merely a comparison of total heights. If another contribution extends 18 above and 2 below the same text baseline, the enclosing CSS line box becomes $18+6=24$ CSS pixels. Both the strut and the other contribution individually total 20. Keeping the separate upper and lower extents explains the extra height.

This construction concerns a CSS line box that participates in layout. CSS also specifies conditions under which empty line boxes are treated as nonexistent, so line-height:20px alone does not make every otherwise empty block 20 CSS pixels high.^[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.

A CSS used value is a value obtained after applying the calculations needed for layout. It can depend on geometry unavailable when the CSS computed value was established, such as the size of a CSS containing block or the sizes of related content.^[ref]

For example, an ordinary block whose computed width remains 50 percent can have a used content width of 200 CSS pixels in a 400-pixel containing block. Changing that containing block to 600 pixels yields 300 pixels, with the same computed percentage and with other constraints held fixed. The changed result follows from layout context rather than from a new source declaration.

A used width is also not necessarily the size of the whole outer box. With content-box sizing, padding, borders and margins are accounted for outside the content width. With box-sizing: border-box, the sizing edge is different. CSS minimum size and CSS maximum size constraints can alter the final result as well.^[ref]

Even after the used value has been determined, drawing on a particular device can require rounding or other permitted approximation. A fractional CSS length and a count of illuminated physical pixels are consequently different measurements. Stating the property, value stage, sizing edge and coordinate units makes a layout calculation reproducible.

CSS vertical alignment concerns the vertical-align property in its applicable formatting contexts. For inline-level content, it aligns boxes relative to the line and neighboring text metrics; on table cells, it controls alignment of cell content under the table rules. The relevant reference is therefore determined by context.^[ref]

For an inline image with zero margins, vertical-align: middle aligns the image's vertical midpoint with the parent's text baseline plus half the parent's x-height. It does not generally place the midpoint on the baseline itself.

A numerical example makes that offset visible. Measure height upward from a parent baseline at zero, and let the parent's x-height be ten pixels. A 20-pixel-high image aligned middle has its centre at $5$, its top at $15$ and its bottom at $-5$ CSS pixels. Aligning its centre at zero would produce a different placement.

A positive length such as vertical-align: 4px raises the applicable inline box from its baseline-aligned position; keywords such as top and bottom use specified line-box relationships instead. These placements contribute to the extent required by a CSS line box, so changing alignment can affect the line as well as one item.

To interpret a result, identify the element's generated box, its margins and the surrounding text metrics. CSS vertical alignment is not a general instruction that centers any arbitrary child inside any arbitrary block container.

A CSS writing mode describes the flow and orientation conventions used to lay out text and boxes. Its components include CSS inline direction, CSS block flow direction and CSS glyph orientation. The properties direction, writing-mode and text-orientation have separate roles in establishing those conventions.^[ref]

The writing-mode property specifies horizontal or vertical flow and the block-flow direction. With horizontal-tb, successive blocks progress downward. With vertical-rl, inline layout is vertical and successive blocks progress from right to left. The suffix rl therefore concerns block progression; it does not by itself specify the order of characters along every line.^[ref]

For a concrete box example, set inline-size: 120px; block-size: 60px; direction: ltr;. Assume a simple unconstrained non-replaced box, without padding, borders, transforms or competing size limits. Under writing-mode: horizontal-tb, its physical width is $120$ CSS pixels and height $60$. Under writing-mode: vertical-rl, its physical width is $60$ pixels and height $120$. The logical inline dimension follows the text-flow axis rather than always naming physical width.^[ref]

Changing direction to rtl in the horizontal example places inline-start on the right, while block-start remains at the top. In the vertical example with direction: ltr, inline-start is at the top and block-start is on the right. These mappings help explain why a CSS scroll origin need not be a physical top-left corner.^[ref]

CSS glyph orientation then controls how individual glyphs are oriented within vertical text. This is different from rotating an already laid-out box: a writing-mode change also affects line arrangement, block progression and the mapping of logical dimensions. Keeping those effects separate makes vertical layouts and direction-dependent interfaces easier to reason about.

The device pixel ratio expresses the size of one CSS pixel relative to one physical device pixel. The CSSOM View Module by World Wide Web Consortium defines window.devicePixelRatio as the current CSS pixel size divided by the output device's vertical pixel size, with page zoom included in the former:The numerator and denominator are physical lengths, so the ratio is dimensionless.^[ref]

At $r=2$, a $300\times 150$ CSS pixel region corresponds to $600\times 300$ device pixels in a uniform mapping. The linear counts double, while the pixel count scales by $r^2=4$. A raster drawing surface can therefore need four times as many stored pixels to supply one sample per device pixel while retaining the same layout size. An existing low-resolution image does not gain missing detail merely because the display has a larger ratio.

The ratio need not be an integer. A ratio such as $1.25$ means that a one-CSS pixel boundary need not align with the physical grid, so rasterization has to distribute coverage. Increasing page zoom changes the size of a CSS pixel and can change the reported ratio. Pinch zoom scales the visual view without redefining the layout pixel in the same way; it is a separate scale.^[ref]

Pixel density in pixels per physical inch and device pixel ratio consequently answer different questions: the former describes a physical grid, while the latter describes its mapping from the browser's layout scale.

The layout viewport is the browser viewport used as a reference for laying out the document. Its dimensions help determine the available layout area and initial containing block. The visual viewport can display a magnified subregion of that layout, so visible width and layout width need not be equal.^[ref]

For an illustrative layout viewport width of 400 CSS pixels, a block filling half of a same-width containing block uses 200 pixels. A fixed-width block declared as width: 600px can instead overflow that region. The viewport's width does not force every element or the whole scrollable document to have that width.

At visual scale two, the user might see only 200 pixels of the existing 400-pixel layout. The half-width block remains 200 layout pixels wide. Increasing page zoom can instead reduce the width available in layout CSS pixels on a fixed physical display, potentially changing wrapping or width-dependent styling. The two operations alter different stages of the geometry.^[ref]

A containing block and a viewport should not be conflated either. Nested elements can size relative to their own containing blocks; the initial document layout has its specified viewport relationship. When measuring a layout, state which viewport or containing block supplied a dimension and whether the reported units are CSS or device pixels. This prevents an overflow measurement, a visible screen region and a layout constraint from being treated as one number.

Typographic leading concerns vertical spacing between lines of type. The term comes from the thin lead spacers used to separate lines of metal type. In current discussion, one must establish whether a quoted value means the complete spacing between text baselines or an additional allowance beyond the chosen font ascent and font descent.^[ref]

CSS leading uses the additional-allowance convention. If a single font contributes ascent $A$ and descent magnitude $D$, and the chosen line height is $H$, thenThe elementary inline-box construction allocates half of $L$ above the ascent and half below the descent. These quantities are font-wide metrics, rather than the actual ink bounding box of each glyph.^[ref]

For hypothetical metrics $A=11$, $D=3$ and $H=18$ CSS pixels, the extra leading is 4 CSS pixels, with 2 on each side. If the same metrics use $H=12$, then $L=-2$: the allocated line region is smaller than the metric extent. Negative CSS leading is allowed, so visible ink can extend outside its line allocation. A line height value must consequently be interpreted together with the font and the layout convention.

Page zoom changes a browser page's layout scale by changing the physical size associated with a CSS pixel. The browser can consequently fit fewer layout units into the available display area and recompute line wrapping and other width-dependent layout. Pinch zoom, represented by the visual viewport scale, magnifies an already laid-out view instead.^[ref]

For an illustrative fixed device width of 800 physical pixels, suppose the initial device pixel ratio is $r_0=2$. The width corresponds to 400 CSS pixels. At page-zoom multiplier $z=2$, with other scaling held fixed, each layout pixel spans four device pixels, so the available width is 200 CSS pixels:A box declared as width: 100px still has that declared width, but its physical display width increases. A percentage-width box or a line of text can respond to the changed containing width instead.

The device pixel ratio API includes the current page zoom when comparing a layout pixel with an output-device pixel. A scale caused by pinch zoom is tracked separately. Reading the ratio alone therefore does not reveal every magnification affecting what a user sees.^[ref]

These equations describe a uniform idealized mapping with fixed display geometry. Browser chrome, available viewport area and extra transforms can change a concrete measurement. The central distinction is which coordinate scale changes: layout is recomputed at a different CSS-to-device mapping under page zoom.

Pinch zoom magnifies a browser's visual view of a page while leaving its layout scale unchanged. The specification describes this through the visual viewport scale factor, which acts like a magnifying glass over the layout viewport. A pinch gesture is a common way to control the scale, but the same visual magnification can be triggered through other interface behavior.^[ref]

For example, suppose the device shows 800 physical pixels across, with device pixel ratio $r=2$ and no initial visual magnification. The visible width is then 400 CSS pixels. At a visual scale $s=2$, the same device width displays only 200 CSS pixels of that existing layout. The user can pan across the enlarged page. A paragraph laid out at a given CSS width does not acquire a new layout width merely because it is viewed through the magnification.

In this simple uniform mapping, a layout length $\ell$ spansdevice pixels. For $\ell =100$ CSS pixels, $r=2$ and $s=2$, the displayed span is 400 device pixels. Additional transforms or browser interface geometry require their own accounting.

Page zoom instead changes the physical size of a layout CSS pixel and can affect layout and the reported device pixel ratio. Pinch zoom does not redefine that ratio in the same way. Combining the two scale factors silently can therefore produce incorrect pointer positions, image-resolution choices or measurements.^[ref]

Pixel pitch is the physical spacing between corresponding centres of neighbouring pixels on a display or sensor grid. For an axis-aligned rectangular grid it can have separate horizontal and vertical values $p_x,p_y$. The pixel pitch describes the grid spacing, rather than the number of bits used for each pixel value.^[ref]

For square pixels on a uniform grid, linear pixel density $\rho$ and pixel pitch $p$ are reciprocal. If $\rho$ is measured in pixels per inch,For example, a hypothetical matrix with 2400 columns occupying a $600\mathrm{mm}$ active width has $p_x=600/2400=0.25\mathrm{mm}$ and horizontal pixel density $25.4/0.25=101.6$ pixels per inch. This calculation treats the width as the edge-to-edge extent of 2400 equal pixel cells; the distance from the first centre to the last centre is instead $2399p_x$.

Doubling the column count over the same width halves the horizontal pixel pitch. Doubling both row and column counts quadruples the number of pixels per unit area. The dimensions and the direction being measured therefore matter when comparing specifications.

A smaller pixel pitch provides a finer sampling grid, but it cannot recover detail already lost from the input image. Optical blur, aliasing and the viewing geometry also affect visible detail. A CSS pixel is a layout unit, so its size must be mapped through the device pixel ratio before it can be related to this physical grid.

A typographic point is a unit used for font size, line height and other typographic distances. In the modern digital convention,Here the inch is 25.4 millimetres. The equation describes the digital convention; historical typographic point systems have not all used that same length. The modern pt relation also appears among the absolute-length units defined for CSS.^[ref]

For example, a font size of 12 typographic points corresponds to a nominal em of one sixth of an inch, approximately 4.2333 millimetres. That sets the outline's scale, rather than the exact ink height of every glyph. A particular x-height or glyph advance can be a different fraction of an em.

The CSS conversion also gives 12 typographic points as 16 CSS pixels. A CSS pixel is a layout unit, so this equality does not promise 16 hardware pixels or a ruler-measured physical height on every screen. Zoom and the mapping to device pixels must be accounted for separately; the device pixel ratio records one part of that mapping.

The visual viewport is the region of the laid-out page currently visible through a browser's view, described by its size, offset and scale. It can show only part of the layout viewport, especially during pinch zoom. The specification exposes this state through the VisualViewport interface.^[ref]

For example, take a layout 400 CSS pixels wide on a display mapping two device pixels to each layout pixel. A visual magnification of two can show only 200 CSS pixels across the same 800-device-pixel area. Panning changes which interval of the layout is visible without requiring the layout itself to become 200 pixels wide.

A simple horizontal coordinate conversion illustrates the need for both offset and scale. If a point has coordinate $x$ relative to the layout viewport and the visual view starts at offset $v_x$, then, with uniform mapping,where $r$ is the device pixel ratio and $s$ the visual scale. With $x=150$, $v_x=100$, $r=2$ and $s=2$, the point appears 200 device pixels from the visual view's left edge. Additional transforms and browser geometry need separate treatment.

Page zoom can change the physical mapping of layout CSS pixels, whereas the visual viewport scale is tracked separately. A program placing an overlay or translating an interaction coordinate must therefore identify its coordinate origin and units before combining measurements.^[ref]

Word spacing is the separation between adjacent words in a line of text. Its nominal value comes from the computer font and layout settings; text justification can adjust it through typesetting glue. Letter spacing instead changes spacing within the text's sequence of letters. A script without visible word separators needs a different spacing strategy from an English sentence.^[ref]

Suppose three typesetting boxes have widths 8, 6 and 10, and the two intervening spaces each have width 3. The natural line width isAdding 1 to each space gives width 32. Adding 1 to every glyph advance would generally produce a different layout, because there need not be one glyph per word or per stored character. Word spacing must therefore be applied to the intended separators rather than inferred from a count of glyphs.

In CSS, word-spacing: 1px specifies additional spacing at the relevant word separators; it does not set every interword gap to exactly one CSS pixel.^[ref]