In CSS Flexbox, why does flex-direction: row lay items out right-to-left when the container's direction is rtl, and what does that mean for how you write layout rules?

## The axes are logical, not physical The flexbox specification never defines `row` as "horizontal". It defines it against the container's **inline axis** — the direction text advances — and `column` against the **block axis** — the direction lines stack. Two CSS properties determine where those axes point: - `writing-mode` chooses whether the inline axis is horizontal or vertical (`horizontal-tb` versus `vertical-rl` / `vertical-lr`). - `direction` chooses which end of a horizontal inline axis is the start (`ltr` versus `rtl`). So the mapping is: | Container context | `row` runs | `column` runs | | --- | --- | --- | | `horizontal-tb`, `ltr` | left → right | top → bottom | | `horizontal-tb`, `rtl` | right → left | top → bottom | | `vertical-rl` | top → bottom | right → left | That is the whole answer to "why does my row reverse itself in Arabic or Hebrew": nothing reversed. The main axis is the inline axis, and the inline axis starts on the right in a right-to-left context. ## What flips for free Because the flex model is expressed in main-start/main-end and cross-start/cross-end terms, a large part of a layout localises itself with no extra code: - The order items are packed in follows the inline direction. - `flex-start` and `flex-end` follow the axis edges, so a rule that pins a control to `flex-end` pins it to the correct visual side in both directions. - The Box Alignment `start` and `end` keywords are likewise writing-mode relative. - Logical spacing properties — `margin-inline-start`, `padding-inline-end` and their siblings — flip with the inline axis. A subtle distinction worth knowing at this level: `flex-start` is *flex-relative* while `start` is *writing-mode relative*. In a `row-reverse` container the two diverge — `flex-start` follows the reversed main axis and lands on the right in a left-to-right context, while `start` stays with the inline-start edge on the left. ## What does not flip Everything physical, which is exactly where bidirectional bugs live: - `margin-left: auto` — the nav-bar trick for pushing an item to the far end. In RTL it pushes to the wrong side. `margin-inline-start: auto` is the direction-aware version. - Physical `padding`, `border-*` and `border-radius` corners. - `left` / `right` offsets on positioned elements, and physical `inset-*` values. - `transform: translateX()`, which is defined in physical coordinates. - `box-shadow` and `text-shadow` horizontal offsets, and physical `background-position` keywords. - Directional content: chevrons, back arrows, sort carets. CSS cannot know that a glyph implies direction; either flip it deliberately or ship a mirrored asset. ```css /* pushes to the wrong side in RTL */ .nav .profile { margin-left: auto; } /* follows the inline axis in both directions */ .nav .profile { margin-inline-start: auto; } ``` ## row-reverse is not an RTL strategy A recurring mistake is to "add RTL support" by switching containers to `row-reverse`. It is wrong on three counts. First, it localises nothing else — text alignment, list markers, physical margins and icons all stay in their left-to-right arrangement. Second, it decouples visual order from document order, so keyboard focus and reading order no longer follow the visuals, which is an accessibility regression rather than a fix. Third, it does not compose: a container that is already `row-reverse` for a genuine visual reason ends up double-reversed under a naive rule. The correct mechanism is to set the direction on the document or subtree and let the logical model do its job. ## Production judgment The senior-level version of this answer is about how you keep a codebase honest rather than how the spec is worded: - **Default to logical.** Flex-relative and inline/block-relative keywords in shared components; physical values only where the thing genuinely is physical, like a drop shadow's light source. - **Make it testable.** A page or story that renders the component tree inside a right-to-left subtree catches the physical leftovers immediately, and it is far cheaper than a translation pass discovering them. - **Watch the scroll and overflow edges.** When the inline axis flips, the edge that overflowing content spills toward flips with it, and so does the initial scroll position. Code that reads or sets scroll offsets and assumes zero means "leftmost" needs review. - **Nested writing modes are real.** A single component can sit in a differently-directed subtree from its parent, so rules that assume one direction for the whole document eventually break. Getting this right is cheap as a convention and expensive as a retrofit, which is precisely why it comes up in senior interviews: the question is not whether you can recite the mapping table but whether you would have written the layout in a way that never needed the retrofit.