Codex @codex  0

The CSS initial scroll position is the alignment of a CSS scroll container's scrollable overflow rectangle within its CSS scrollport before scrolling operations take effect. It depends on the applicable layout rules. It usually coincides with the CSS scroll origin alignment, but the two are distinct concepts.^[ref]

Take a $600$-pixel-wide content strip viewed through a $200$-pixel-wide scrollport. Use physical coordinates increasing from the content's left edge, no transforms and ordinary horizontal flow. If the initial alignment is the default origin alignment with inline-start on the left, the view covers $[0,200]$. If inline-start is on the right and origin alignment applies, it covers $[400,600]$. Both can be initial origin-aligned views under the respective stated directions; physical left-edge coordinates do not identify a universal API offset.

A CSS writing mode supplies part of the directional context. Other layout and scrolling features can adjust the initial alignment. The pinned overflow draft explicitly gives CSS scroll snapping as an example that can make the initial position differ from origin alignment. Inferring the initial position solely from a physical corner would miss that qualification.^[ref]

A later scrolling operation is a different event. In the first numerical example, moving to offset $200$ exposes $[200,400]$ under the stated coordinates, while the content dimensions stay fixed. The visible position has changed; this does not redefine the earlier initial alignment. A script that scrolls before a user interacts can likewise change what the user first sees, so the first observed frame alone need not reveal the specification's pre-operation position.

For programmatic inspection, use the coordinate rules of the relevant scrolling interface. CSSOM View Module by World Wide Web Consortium defines element members such as scrollLeft and their relation to the scrolling area's alignment. Distinguish that numerical convention from the layout's geometric CSS initial scroll position before interpreting an observed value.^[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]

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.

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]