CSS scrollport

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.

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]

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]