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 inline direction is the base directionality used for text within a line and for related direction-dependent layout. The direction property selects ltr or rtl; together with CSS writing mode, this establishes the mapping of logical inline-start and inline-end to physical directions.^[ref]

For a horizontal example with ordinary start-aligned text, direction: ltr places inline-start at the left edge, while direction: rtl places it at the right. A label aligned to inline-start can consequently change sides without changing its source text. In vertical writing, interpreting inline-start requires the writing-mode mapping too; it is not always a physical left or right edge.

Base direction is not an instruction to reverse every letter. The Unicode Bidirectional Algorithm considers the directional properties of text and the surrounding embedding or isolation context. A left-to-right sequence such as ABC can retain its internal order inside a right-to-left paragraph. CSS uses that algorithm rather than treating a string as an undifferentiated list to reverse.^[ref]

For HTML, the specification recommends expressing a document's directional semantics with markup such as <p dir="rtl">ABC</p> instead of depending solely on a CSS override. That example establishes a right-to-left paragraph base; it does not promise the visible sequence CBA. Keeping the directional information in the document also preserves it when styling is unavailable.^[ref]

CSS block flow direction remains a separate choice. A right-to-left horizontal paragraph still participates in a top-to-bottom block flow under horizontal-tb. Conversely, vertical lines can progress across a page under the block rules while their inline base direction follows its own mapping.

The scope of an override matters as well. A direction declaration on an ordinary inline box with unicode-bidi: normal does not by itself open a new embedding level for reordering. Diagnose the box's direction, its writing mode and the relevant bidirectional scope together.^[ref]

CSS inline size is a box's extent parallel to text flow within a line. It corresponds to physical width in a horizontal CSS writing mode and physical height in a vertical writing mode. The inline-size property provides the corresponding flow-relative sizing control.^[ref][ref]

For an own definite-size example, let inline-size: 180px; block-size: 60px; apply to a simple box with no padding, borders or competing constraints. Under horizontal-tb, the physical rectangle is $180$ by $60$ CSS pixels. Under vertical-rl, it is $60$ by $180$. Inline size remains $180$ in both descriptions because the inline axis changes with the writing mode.

CSS box-sizing determines which box dimension a declared size constrains. For example, with box-sizing: border-box; inline-size: 80px;, ten-pixel padding and two-pixel borders on each inline side leavepixels of content extent along that axis, assuming no other sizing constraint intervenes. The outer inline extent is eighty, not fifty-six.

Logical and physical properties can address the same underlying dimension. With equal cascade priorities in horizontal writing, width: 100px; inline-size: 200px; supplies a later declaration for the same physical width, so the latter wins. In vertical writing, width and inline-size address different dimensions: physical width can be $100$ while physical height is $200$.^[ref]

A direction reversal alone does not change which physical axis is inline. Changing CSS inline direction from left-to-right to right-to-left can exchange inline-start and inline-end without converting a horizontal inline size into height. Likewise, CSS block size measures the perpendicular axis.

Real used sizes can also depend on min/max constraints, available space and the layout algorithm. State the writing mode and box-sizing convention before interpreting an inline-size value as a visible physical width.

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

The CSS typographic mode determines whether text uses typographic conventions specific to vertical flow or is treated as horizontal typography. This distinction is separate from the orientation of the CSS writing mode: text can occupy a vertical flow while retaining horizontal typographic treatment.^[ref]

Under writing-mode: horizontal-tb, both writing mode and typographic mode are horizontal. Under vertical-rl or vertical-lr, both are vertical. Under sideways-rl or sideways-lr, the writing mode is vertical but the typographic mode is horizontal. Thus the suffix that names block progression does not by itself identify the typographic conventions.^[ref]

For an illustrative token 漢A, compare vertical-rl with text-orientation: mixed against sideways-rl. In the first case, the vertical-script glyph receives its intrinsic vertical orientation while the Latin letter is sideways. The second mode treats the run as horizontal typography presented sideways. Both have right-to-left CSS block flow direction, but they need not produce the same glyph treatment.^[ref]

This distinction matters for font selection of vertical glyphs, orientation and alignment. Vertical typesetting can use vertical metrics and alternate glyph forms rather than simply rotate all horizontal outlines. The example describes the specified categories, not an exact pixel measurement for every font.^[ref]

CSS glyph orientation is another related layer of control. In the pinned specification, text-orientation has an effect only in vertical typographic modes; setting it on a box using horizontal typographic mode does not turn that mode into vertical typography.^[ref]

Keep CSS inline direction, block progression and typographic treatment distinct when diagnosing a vertical label. A change in the visible arrangement can come from different stages of the layout and text shaping process, so a single whole-box CSS transform is not a general substitute for specifying the intended typography.

A CSS writing mode describes the flow and orientation conventions used to lay out text and boxes. Its components include CSS inline direction, CSS block flow direction and CSS glyph orientation. The properties direction, writing-mode and text-orientation have separate roles in establishing those conventions.^[ref]

The writing-mode property specifies horizontal or vertical flow and the block-flow direction. With horizontal-tb, successive blocks progress downward. With vertical-rl, inline layout is vertical and successive blocks progress from right to left. The suffix rl therefore concerns block progression; it does not by itself specify the order of characters along every line.^[ref]

For a concrete box example, set inline-size: 120px; block-size: 60px; direction: ltr;. Assume a simple unconstrained non-replaced box, without padding, borders, transforms or competing size limits. Under writing-mode: horizontal-tb, its physical width is $120$ CSS pixels and height $60$. Under writing-mode: vertical-rl, its physical width is $60$ pixels and height $120$. The logical inline dimension follows the text-flow axis rather than always naming physical width.^[ref]

Changing direction to rtl in the horizontal example places inline-start on the right, while block-start remains at the top. In the vertical example with direction: ltr, inline-start is at the top and block-start is on the right. These mappings help explain why a CSS scroll origin need not be a physical top-left corner.^[ref]

CSS glyph orientation then controls how individual glyphs are oriented within vertical text. This is different from rotating an already laid-out box: a writing-mode change also affects line arrangement, block progression and the mapping of logical dimensions. Keeping those effects separate makes vertical layouts and direction-dependent interfaces easier to reason about.