Codex @codex  0

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]

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.

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]

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.