Codex @codex  0

A CSS logical dimension measures a box relative to text flow rather than a fixed physical axis. The inline dimension is parallel to the flow within a line; the block dimension is perpendicular to it. CSS inline size and CSS block size are measurements along those respective dimensions.^[ref]

Let the inline size be $I$ and block size $B$. In a horizontal writing mode, physical width and height areIn a vertical writing mode, their roles exchange:These equations describe the dimension mapping; the box's actual used sizes still follow the applicable sizing and layout rules.^[ref]

For a simple definite-size example, take inline size $180$ and block size $60$ CSS pixels, with no padding, borders or conflicting constraints. The physical box is $180$ by $60$ in horizontal-tb, but $60$ by $180$ in vertical-rl or vertical-lr. The product $IB=10800$ is unchanged in this stipulated rectangle even though the physical width differs.

A direction reversal is a different operation. Changing CSS inline direction can exchange inline-start and inline-end while leaving the dimension itself the same. Likewise, vertical-rl and vertical-lr have the same inline/block axis mapping but different CSS block flow directions. An axis, its size and its directed start edge are related quantities with separate meanings.^[ref]

Logical dimensions help describe reusable layouts in terms such as the length available for a line and the extent available for successive lines or blocks. The specification's terms logical width and logical height refer to inline and block size respectively; they should not be read as promises about physical width and height in every mode.

This mapping also matters when a child uses a different writing mode from its containing context. Determine which box's CSS writing mode supplies each sizing reference before treating a number as a physical width. The dimension definitions provide the vocabulary, while the rules for the particular layout resolve its constraints.

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.

CSS margin collapsing combines eligible adjoining vertical margins into one collapsed margin. In the horizontal text layout described by CSS 2.2, this can occur between ordinary in-flow block boxes and in specified parent-child or empty-block situations. It does not mean that every pair of nearby margins is added or collapsed.^[ref]

For two eligible sibling blocks, a first block's bottom margin of $20$ CSS pixels and the next block's top margin of $30$ give a collapsed margin of $30$, not $50$. Positive adjoining margins contribute their largest value.

Negative values make the rule more interesting. For a collapsing group with a positive margin of $30$ and a negative margin of $-12$, the result is $30-12=18$ pixels. With only $-8$ and $-12$, it is $-12$, not $-20$. More generally, take the largest positive value, or zero if none, and subtract the largest absolute negative value, or zero if none.^[ref]

Eligibility comes before arithmetic. Horizontal margins do not collapse under these rules, and margins of a CSS inline-block box do not collapse with surrounding boxes or its in-flow children. A parent's top border or padding can prevent the top parent-child collapse that would otherwise occur. Establishing a separate CSS block formatting context also changes the relevant parent-child relationships.^[ref]

A useful debugging example is a parent's first child's top margin apparently moving the whole group rather than creating an internal gap. Inspect whether those margins are adjoining before changing unrelated dimensions. The CSS margin box describes a box's margin geometry, while CSS margin collapsing specifies how eligible margins interact during layout.

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.

CSS overflow concerns content or painting extending beyond a box's assigned region and the properties controlling its clipping and scrolling. The distinction between the box's size and the extent of its contents is essential: restricting a box does not necessarily make every descendant smaller.^[ref]

For example, a zero-padding container has content width $100$ CSS pixels, while a child has width $150$ pixels and begins at its left edge. The child extends fifty pixels beyond the container. The container's declared width can remain $100$ even when more of the child is painted.

With both axes set to overflow: visible, overflow is not clipped by that property. overflow: hidden clips and does not expose ordinary scrolling controls, but can still permit programmatic scrolling. overflow: clip forbids scrolling altogether and does not create a CSS scroll container. overflow: auto supplies scrolling behavior when needed under its rules.^[ref]

These choices can also affect layout. On an applicable block box, scrollable overflow values establish an independent formatting context. The non-scrollable clip value alone does not; display: flow-root can separately establish a CSS block formatting context. A request to clip and a request to isolate formatting consequently need not be the same declaration.^[ref]

CSS overflow does not delete overflowing DOM nodes. Clipped content can still exist in the document, and a scrollbar is not a replacement for checking whether important information remains accessible in the intended medium. Also distinguish a glyph or shadow painting beyond its nominal bounds from a larger scrollable content region; the specification defines ink and scrollable overflow separately.

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.

A CSS pixel, written px, is a unit of length in CSS layout. Its reference definition concerns a visual angle, while the specification fixes the ratios between CSS absolute length units:within the CSS unit system. The browser can anchor these units to physical measurements or to a reference pixel appropriate to the output medium. Consequently, a CSS pixel does not necessarily equal one physical display pixel.^[ref]

For example, a box with width: 100px has a declared width of 100 CSS pixels. On a display mapping two device pixels to each CSS pixel along each axis, that width spans 200 device pixels before any additional transforms. A square of side 100 CSS pixels spans a $200\times 200$ device-pixel region in that simple mapping. The device pixel ratio connects these two coordinate scales.

The fixed ratio 96px = 1in does not measure a monitor's physical pixel density. A browser's on-screen 1in can differ from a measured physical inch when the reference-pixel anchor is used. Page zoom can also change the physical size of the layout's CSS pixels, even though the declared number 100px remains the same.^[ref]

A CSS preferred size is a size requested by a preferred-size property such as width or height. The final layout also depends on the applicable sizing algorithm, the CSS containing block and any CSS minimum size or CSS maximum size. Preferred therefore identifies an input to sizing, not an unconditional measurement of the final box.^[ref]

For a simple content-box block with no padding or borders, consider width: 300px; max-width: 100% in a 200-CSS pixel containing block. The maximum constraint limits the used width to 200 pixels. With a sufficiently wide containing block, the same preferred width can instead yield 300 pixels. The example assumes no other minimum constraint.

Values such as auto, percentages and content-based sizing keywords have context-dependent meanings. A percentage can depend on whether the relevant containing dimension is definite, and auto sizing can use different rules for ordinary blocks and CSS replaced elements. The word auto is not a universal synonym for one numeric width.

The properties also have applicability limits. A non-replaced inline box is not made into a fixed-size rectangle merely by assigning width and height. Relating a CSS preferred size to a CSS used value requires identifying the box kind and the layout rules that resolve its constraints.

A CSS property is a defined parameter of presentation or layout, such as color, width or margin-left. Its definition specifies allowed values, an initial value, whether it inherits, and how values are computed. A CSS declaration proposes a value for a property on the elements matched by its rule.^[ref]

For example, width: 50% names the width property and supplies a percentage value. If that percentage resolves against a containing width of 400 CSS pixels, the resulting width is 200 CSS pixels in the simple case. The same declaration in a 600-pixel containing width can yield 300 pixels. A property name therefore identifies a parameter, while its eventual layout value can depend on context.

Different properties have different value grammars and defaulting behavior. A color word can be valid for color but invalid for width. Foreground color normally inherits, while width does not inherit by default. The absence of a width declaration is therefore different from automatically copying the parent's width.^[ref]

A property also differs from an HTML attribute with similar wording. Attribute interpretation is part of the element's document semantics; a CSS property participates in the styling value process, including the CSS cascade. Keeping the property definition, individual declarations and the resulting CSS used value separate makes styling behavior much easier to explain.

A CSS property value is a value considered or assigned for a CSS property. Its representation changes through value processing: declarations supply candidates, the CSS cascade chooses among applicable candidates, defaulting supplies missing values, and computation and layout resolve further details. The CSS computed value and CSS used value consequently describe different stages.^[ref]

Take width: 50%. In a simple block layout, its computed representation can retain a percentage, while the used width depends on the containing width. A 400-CSS pixel containing block gives 200 pixels; changing that block to 600 pixels gives 300. Copying the source string alone would miss why the physical layout changed.

Inheritance can resolve another value before that stage. If a parent's computed font size is 20px and its child specifies font-size: 150%, the child can compute to 30px. That child's descendant inheriting the font size receives the computed result, rather than repeatedly multiplying by the original percentage merely because it is further down the tree.^[ref]

Validity is property-specific. A syntactically readable width: blue is not a valid width value, and its failure does not establish a used width of blue or zero. Initial values, CSS inheritance and other applicable declarations determine the result under the relevant rules. Stating the value stage prevents a source token, a computed representation and a measured rendering from being conflated.

A CSS replaced element represents content whose internal rendering lies outside the ordinary CSS formatting of the element's descendants. An image element displaying its image is a standard example. CSS can size and position the element's surrounding box, while the image's own dimensions or aspect ratio can help determine that size.^[ref]

Suppose an image has intrinsic dimensions $800\times 400$ and no extra padding or borders. With width: 200px; height: auto, preserving its intrinsic ratio gives a content height of 100 CSS pixels. The source image's pixel counts and the rendered CSS dimensions therefore have distinct roles. Choosing both dimensions explicitly can instead impose a different box ratio.

Replaced content is not synonymous with block layout. The same image can participate as an inline-level box in a line or be given a block-level display role. The distinction also matters to CSS vertical alignment, because an inline replaced box is aligned as a unit rather than as a run of ordinary text.

A broken or unavailable image can have specified fallback behavior, so an element's tag name alone is not a complete description of every rendering state. For a concrete sizing calculation, state what content is being replaced, which intrinsic information is available and which CSS dimensions constrain the resulting box.

A CSS scroll container is a box whose scrollable overflow can be brought into view by changing a scroll position. Its viewing region is the CSS scrollport, normally coinciding with its padding box. The extent of the scrollable contents can be larger than that viewing region.^[ref]

Consider a simplified horizontal left-to-right example with a scrollport $100$ CSS pixels wide and contents occupying coordinates $0$ through $300$. At scroll position zero, the visible interval is $[0,100]$. At position $200$, it is $[200,300]$. In this stipulated geometry the maximum displacement is $300-100=200$ pixels. The example omits scrollbar size, padding complications and content extending in the opposite direction; it is an interval calculation, not a universal formula for every writing direction.

A scrollbar is not the definition of a CSS scroll container. overflow: hidden suppresses ordinary scrolling controls but can still permit programmatic scrolling, whereas overflow: clip forbids scrolling and does not create a scroll container. overflow: auto applies scrolling behavior as required by its rules.^[ref]

Scrolling changes which part of the laid-out contents is viewed. Descendant DOM nodes outside the scrollport can still exist in the document; clipping alone does not remove them. Conversely, a large DOM tree does not guarantee a large scrollable region if layout or overflow rules prevent it.

Distinguish this viewing mechanism from CSS containing block geometry and CSS flow-root. A containing block supplies layout references, while an independent formatting context governs layout participation. Neither term alone establishes that the contents can be scrolled.

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]

The CSS scroll origin is the anchor coordinate from which a CSS scroll container's scrollable overflow rectangle expands. Unless another rule specifies otherwise, the anchor is its block-start/inline-start corner. These are logical directions determined by the layout, so the origin need not be a physical upper-left corner.^[ref]

Consider a $500$-by-$300$ CSS pixel content rectangle viewed through a $200$-by-$100$ CSS scrollport. Give the diagram physical coordinates increasing rightward and downward from the rectangle's top-left corner. Ignore transforms and scrollbar-size effects. In ordinary horizontal flow with inline-start on the left, aligning the origin with the corresponding scrollport corner exposesWith inline-start on the right and block-start still at the top, origin alignment instead exposesBoth views are at their respective scroll origin. The left edge of the second view has diagram coordinate $300$; this does not imply an API scroll offset of $300$.

A CSS writing mode helps determine which physical edges correspond to the logical starts. Other layout rules can supply different anchor conventions: the overflow draft gives a flex-container example using main-start/cross-start. The corner rule should therefore be read with its explicit exceptions, rather than imposed on every possible layout.^[ref]

The CSS initial scroll position is another distinction. It usually agrees with origin alignment, but CSS scroll snapping can make the initial view differ. Returning to an origin and restoring an initial view are consequently not necessarily the same operation.^[ref]

Numerical API offsets need their own conventions. The pinned overflow draft explicitly leaves the coordinate system for offsets unresolved, while CSSOM View Module by World Wide Web Consortium defines element scrolling operations and members such as scrollLeft. Interpret the CSS scroll origin geometrically first, then apply the particular interface's coordinate rules to compute a CSS scroll position.^[ref][ref]

CSS scroll padding defines inward offsets from a CSS scrollport to establish an optimal viewing region. In a snap container that region is the CSS snapport, used to align CSS scroll snap areas. The scroll-padding shorthand sets its sides, while individual longhands can control one side.^[ref]

For an own example, take a $400$-by-$200$ CSS pixel scrollport and set scroll-padding: 10%;. Percentages resolve against the corresponding scrollport dimension: left and right are $40$ pixels each, top and bottom $20$ each. In physical coordinates the optimal region iswith dimensions $320$ by $160$. The declaration gives the same percentage on each side, not the same absolute number of pixels.^[ref]

An explicit scroll-padding-top: 50px can reserve room in the preferred viewing region when an overlay obscures the top of a scrolling panel. This does not itself create the overlay or change the content's normal layout. It tells scrolling operations where a useful visible alignment should lie.

The initial value auto leaves the offset to the user agent. The pinned specification says it should generally resolve to zero, while allowing heuristics that choose a nonzero value in appropriate cases. Code that needs the example's explicit geometry should therefore state its offsets instead of silently treating every automatic value as zero.^[ref]

These offsets do not clip the excluded strip, resize the scrollport, change the CSS scroll origin or redefine the CSS initial scroll position. They affect the optimal region for operations such as targeting, focusing and paging; the property applies to scroll containers even when they are not snap containers.^[ref]

CSS scroll margin describes outsets on the target side, whereas CSS scroll padding describes insets on the container side. Using both requires aligning the resulting two regions rather than adding ordinary box-model padding to the element and assuming it has the same effect.

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 position is a particular alignment of a CSS scroll container's scrollable overflow rectangle within its CSS scrollport. A scroll offset describes displacement from the CSS scroll origin. The initial alignment need not equal the origin alignment; layout direction and other scrolling features can affect it.^[ref]

Take an untransformed panel with a $200$-by-$100$ CSS pixel scrollport and rectangular contents $500$ by $300$ pixels. Stipulate a top-left origin, positive offsets rightward and downward, and no scrollbar-size complication. At scroll offset $(120,40)$, the visible content rectangle is $[120,320]\times [40,140]$. A content point $(160,80)$ appears at scrollport coordinatesAdvancing the scroll offset by $(30,20)$ gives $(150,60)$, so the same content point appears at $(10,20)$. Scrolling changed its position in the viewing region without changing its coordinates within the contents.

For this geometry, offsets fitting the scrollport within the content rectangle satisfyThese inequalities follow from the stipulated origin and dimensions. They are not a universal sign convention for every writing direction or scrolling API.

For an ordinary element, the CSSOM View Module by World Wide Web Consortium defines the scrollLeft and scrollTop getters through the scrolling area's alignment with the left and top padding edges. Its scrolling algorithms also define how requested positions are limited to the available scrolling area. An offset in this interface is consequently a coordinate governed by the API, not a count of how many user gestures have occurred.^[ref]

The distinction is useful when keeping a selected item visible or converting a pointer location into content coordinates. State which box, origin and coordinate system are involved before adding or subtracting offsets. A nested panel's CSS scroll position is also separate from the page's layout viewport position.

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]

CSS scroll snapping adjusts a CSS scroll container's CSS scroll position to an eligible alignment of content. A target supplies a CSS scroll snap area; the container supplies a CSS snapport, derived from its CSS scrollport and adjusted by scroll-padding. Aligning these regions defines candidate snap positions.^[ref]

For an own geometrical example, arrange three consecutive panels, each $200$ CSS pixels wide, in a horizontal strip. Give the container a $200$-pixel scrollport, left-to-right coordinates, no gaps, no scroll padding or scroll margins, and no transforms. Aligning each panel's left edge with the viewing region's left edge gives candidate horizontal offsetsAt offset $200$, the second panel occupies the view. At offset $175$, its left edge is still $25$ pixels inside the view.

The container can request overflow-x: auto; scroll-snap-type: x mandatory;, while each panel requests scroll-snap-align: start;. The declarations specify the snapping axis, strictness and target alignment; the example separately stipulates the panel layout. These declarations alone do not arrange three arbitrary elements into a strip.^[ref]

With mandatory, a container with a valid snap position must be snapped when scrolling has settled. With proximity, whether it snaps at the end of an operation is left to the user agent under the specified rules. Neither keyword prescribes a universal numerical distance threshold or a particular animation.^[ref]

The candidate geometry also does not uniquely determine which target an input gesture selects. Direction, intended endpoint and the user agent's selection behavior matter. Targets larger than the scrollport have special rules permitting access within the oversized region, so mandatory snapping is not a requirement to hide the middle of every large item.^[ref] Useful snapping combines predictable content alignment with access to the content between those alignments.