CSS Logical Properties Table
| Physical | Logical | Field note |
|---|---|---|
margin-left | margin-inline-start | start = where reading begins - flips for RTL scripts automatically |
margin-right | margin-inline-end | The inline axis runs along the text flow, whatever direction it flows |
padding-top | padding-block-start | block axis = across the text flow; vertical in horizontal writing |
width | inline-size | The dimension you size follows the text, not the screen edge |
height | block-size | Same swap - block-size of a paragraph grows as lines wrap |
top / left | inset-block-start / inset-inline-start | inset-* replaces all four offset sides in flow terms |
text-align: left | text-align: start | The VALUE is logical too - left breaks RTL, start never does |
border-top-left-radius | border-start-start-radius | Corner names compose: block/inline x start/end |
max-width | max-inline-size | Container queries measure cqi against this same inline axis |
Physical properties describe the screen - left is always the left edge. Logical properties describe the TEXT FLOW: start means where reading begins, which is the left in English, the right in Arabic and Hebrew, and the top in vertical Japanese. Same layout intent, every writing direction.
Bottom line: replace margin-left with margin-inline-start once and the identical stylesheet mirrors for RTL languages with no [dir=rtl] override file - internationalization by construction instead of by duplication. Flow-relative sizing (inline-size, block-size) survives writing-mode and container changes the same way.
The honest part: physical names are not wrong - they are just screen-locked. Pixel-locked decoration (a box-shadow offset, a background-position for a fixed sprite) is fine physical. The rule: if the spacing or sizing exists to follow the CONTENT, write it logical; if it exists to hit a specific screen spot, physical is honest.
How to use
- Swap the axis words: left/right become inline-start/inline-end, top/bottom become block-start/block-end - the flow axes replace the screen edges.
- Use text-align: start instead of left - the value is logical too, and it is the one line most RTL layouts were missing.
- Adopt in new code without bulk rewrites: mixed codebases work fine because logical and physical properties simply cascade separately per box.
Frequently asked questions
Why do logical properties mirror RTL layouts for free?
Because they are defined against the writing mode, not the viewport: when direction: rtl applies, the inline axis flips and every inline-start property follows it. A card list built with margin-inline-start and padding-inline-end needs no second stylesheet - the browser recomputes which physical side that is. The old workflow (duplicate every spacing rule under [dir=rtl] with sides swapped) is exactly the maintenance debt this naming removes; direction and writing-mode are all the switch the browser needs.
Do inline-size and block-size replace width and height everywhere?
They replace them where the dimension should follow the text flow: inline-size of a paragraph runs along the reading direction (horizontal in English, vertical in writing-mode: vertical-rl) and block-size grows across it as lines wrap. For media with intrinsic orientation - an image 400px wide regardless of language - plain width stays natural and clearer. The practical split: layout containers and text blocks go logical, replaced elements with intrinsic sizes stay physical unless they must reflow with writing mode.
How do inset logical properties change positioned elements?
top, right, bottom and left on positioned elements get flow-relative counterparts: inset-block-start, inset-inline-start and the shorthand inset: 0 logical siblings. An absolutely positioned badge at inset-inline-end: 8px sits on the trailing side of the text flow - right side in English, left side in Arabic - with zero extra rules. The corner-radius family composes the same way: border-start-start-radius names the corner where both flow axes begin, whatever physical corner that is in the current writing mode.
Should an existing project migrate all physical properties to logical?
No - migrate forward, not backward. Bulk rewrites risk visual regressions in every RTL locale at once and churn review for no user-visible gain in LTR-only products. The working pattern: all NEW components use logical names, any file you touch for RTL support converts the rules it needs, and truly screen-locked decoration (shadows, sprite positions) stays physical deliberately. Logical and physical properties coexist cleanly - they cascade independently, so a component can adopt them one rule at a time.