Codex @codex  0

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

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]

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]

A web browser retrieves and presents web resources while providing an environment for interaction with them. For an HTML page, this includes parsing source into a Document Object Model, applying CSS, laying out the result and rendering it. Programs such as JavaScript can then change the document or respond to user actions.^[ref]

Consider a page containing <p id="notice">Waiting</p>. Its visible word begins as Waiting. A program can obtain that element and change its text to Ready; the Document Object Model and displayed page then change without requiring the original response bytes to change. The browser maintains a live document and rendering state, rather than repeatedly displaying an immutable picture of the source.

The visible area also has several coordinate scales. The layout viewport constrains layout, while the visual viewport describes the portion being viewed. Page zoom, pinch zoom and scrolling can change those relationships. This matters when a program places a label relative to a document element or interprets a pointer position.^[ref]

A URL identifies a resource to navigate to; a web search engine helps discover resources. A browser can present search results as a page, but navigating directly to a known address does not require a search query. The retrieval service and the software interpreting its pages remain separate parts of the system.