What does writing-mode: vertical-rl do to an element's block and inline axes, and which physical dimension does inline-size then control?

## What the value actually says The `writing-mode` keyword names two things at once: the direction text advances within a line, and the direction lines stack. - `horizontal-tb` — text horizontal, lines stack top-to-bottom. The initial value. - `vertical-rl` — text vertical (top-to-bottom), lines stack right-to-left. - `vertical-lr` — text vertical, lines stack left-to-right. So `vertical-rl` reads as "vertical text, blocks flow right-to-left". The first line of a vertical Japanese page sits against the right edge and each subsequent line is added to its left, which is exactly how a printed novel in that language is set. ## The axis consequences Under `vertical-rl`: | Logical | Physical | |---|---| | inline-start | top | | inline-end | bottom | | block-start | right | | block-end | left | | inline-size | rendered height | | block-size | rendered width | `direction: rtl` combined with `vertical-rl` flips only the inline pair, putting inline-start at the bottom. This is where the payoff of logical properties becomes concrete. A component written as: ```css .note { border-inline-start: 3px solid; padding-inline-start: 1rem; max-inline-size: 40ch; } ``` keeps its meaning — a rule bar at the start of each line, a gutter after it, and a capped line length — whether the bar renders on the left, the right, the top or the bottom. The physical equivalent would draw the bar on the left in every writing mode, which is simply wrong for a vertical column. ## Things that surprise people the first time **Overflow and scrolling rotate too.** In `vertical-rl` the block direction is right-to-left, so a long document's scroll progress runs leftward and the scroll container gains a horizontal scrollbar rather than a vertical one. Code that assumes "long content means vertical scrolling" breaks. **The property inherits.** Setting `writing-mode: vertical-rl` on a wrapper flips the entire subtree, including components that were never designed for it. Scope it deliberately. **Percentage sizing follows the flow, not the screen.** Percentages on `padding` and `margin` resolve against the containing block's inline size, and in a vertical writing mode that inline size is a *height*. A `padding-inline: 5%` that looked stable horizontally can behave very differently once rotated. **Latin text needs `text-orientation`.** In a vertical mode, Latin characters are rotated sideways by default (`text-orientation: mixed`). `text-orientation: upright` keeps each glyph upright and stacks them, which is what you want for short Latin runs inside CJK text but not for whole sentences. ## The non-CJK use case Most engineers meet `writing-mode` not through Japanese typography but through rotated labels: ```css th.rotated { writing-mode: vertical-rl; text-orientation: mixed; } ``` Compared with `transform: rotate(-90deg)`, this keeps the text *in layout*: the cell reserves real space for the rotated run, the text wraps and is selectable normally, and there is no need to compensate for a transformed box that no longer affects its parent's size. That difference — layout participation versus a visual-only transform — is the point an interviewer is usually probing. ## Relationship to direction `writing-mode` and `direction` are orthogonal and both inherited. `writing-mode` decides the orientation of the two axes; `direction` decides which end of the inline axis is the start. You need both to fully resolve any logical property, which is why the mapping question is never answerable from one of them alone.