CSS Logical Properties for RTL-Ready Layouts

A stylesheet full of left margins and right-aligned controls can become expensive to adapt for right-to-left content. Logical properties describe the start and end of the writing axes instead of physical screen edges. That lets many layout relationships follow the document direction automatically.

Separate direction from physical placement

Use the PX to REM Converter to normalize existing spacing values before changing property names. Converting a sixteen-pixel gap at a sixteen-pixel root gives one rem, but the important refactor here is changing which edge receives that gap, not changing the unit system.

Classify declarations by intent. “Space before the label” is a logical relationship. “Keep the map compass in the upper-right corner” might be intentionally physical. Replacing every occurrence of left and right mechanically can damage the latter while helping the former.

Set the document or component direction in HTML when it represents content direction. Do not use CSS direction merely to reverse a row visually. Direction affects text layout and other behavior, so it should describe the content rather than act as a generic alignment trick.

Learn the inline and block axes

The inline axis follows text within a line. The block axis follows the progression of lines or blocks. In ordinary horizontal English content, inline is horizontal and block is vertical, but writing modes can change that mapping.

.settings-panel {
padding-block: 1.5rem;
padding-inline: 1rem;
border-inline-start: 0.25rem solid #5064b8;
max-inline-size: 40rem;
}

.settings-row {
display: flex;
align-items: center;
gap: 0.75rem;
}

.settings-row__action {
margin-inline-start: auto;
}

.settings-description {
margin-block: 0.5rem 0;
text-align: start;
}

This creates direction-aware spacing without separate LTR and RTL rules. The action’s auto margin consumes space before it on the inline axis, placing it at the inline end of the row when the flex direction follows the normal row direction.

Read MDN’s logical properties guide for the mapping rules. Logical properties are not abbreviations for fixed physical edges; their value is that the mapping depends on writing mode and direction.

Migrate by property family

Start with margins and padding because their intent is often easiest to identify. Replace horizontal pairs with margin-inline or padding-inline when both sides have the same purpose. Use start and end longhands when the values differ or only one edge should receive spacing.

Then review logical sizing such as inline-size, block-size, min-inline-size, and max-inline-size. These are particularly useful in reusable components whose text flow should determine the relevant dimension. They are less appropriate when a physical canvas dimension is genuinely the requirement.

Borders have logical counterparts too. A leading accent can use border-inline-start; a separator between stacked items can use border-block-end. Corner radii also have logical forms, but their names require more care because they combine block and inline corners.

Avoid leaving contradictory physical and logical declarations scattered through the same cascade. They may resolve to the same underlying edge, with source order deciding which wins. A refactor that looks harmless in LTR can expose the conflict only after the direction changes.

Review flex direction, positioning, and icons

A normal flex row follows the inline direction. You do not usually need row-reverse just because the document is RTL. Combining both can reverse the arrangement twice and produce an order that differs from what the content requires.

Keep source order meaningful. Logical spacing can move an action to the far edge without changing the document sequence. Do not use order values or row reversal to repair markup that should have been written in a clearer sequence initially.

For positioned elements, use logical insets when the attachment is to the start or end of text flow. Keep physical insets when the design truly refers to a screen edge. Transforms remain geometric operations; a translateX() value does not automatically become direction-aware because surrounding margins are logical.

MDN’s direction reference explains the effect of direction on layout. Directional icons need separate review: a back arrow may need mirroring, but a brand mark or a play symbol usually should not be flipped simply because the page direction changed.

Test mixed content rather than mirror screenshots

Create a component fixture with dir="rtl" and realistic RTL text. Then include a Latin product name, an email address, a number, and punctuation. Bidirectional content can expose issues that a purely mirrored English screenshot cannot represent.

Use HTML direction attributes for content whose direction needs explicit handling, and consider dir="auto" for user-entered fragments when appropriate. A deep treatment of bidirectional text is separate from replacing layout properties, but the two concerns meet in real components.

The W3C internationalization direction guide is a useful authoritative reference. Compare the same component in both directions and inspect borders, controls, inset elements, and text alignment rather than checking only whether the outer panel moved.

Existing guidance on design tokens can help keep spacing values consistent while you migrate. Tokens should express reusable values; logical properties express where those values apply. Changing one does not automatically solve the other.

Add direction fixtures to the project’s HTML and CSS examples. A simple pair of rendered components is often enough to catch a future physical margin reintroduced by a hurried patch. Include nested direction changes if embedded content can legitimately differ from the page.

Document the remaining physical declarations instead of treating them as failures. A photo crop, chart axis, or fixed map control may intentionally reference physical coordinates. The goal is accurate layout intent, not a stylesheet that wins a search for zero occurrences of left and right.

Finally, review shorthand declarations carefully. A four-value physical margin encodes top, right, bottom, and left in a way that is easy to misread during migration. Expand it temporarily, establish the intended relationships, and then choose logical shorthands that make those relationships obvious.

Key takeaways

• Use logical properties for relationships tied to text flow.
• Keep intentionally physical geometry physical and document why.
• Migrate spacing, sizing, borders, and insets as separate families.
• Avoid double reversal with RTL direction and row-reverse.
• Test realistic mixed-direction content, not only mirrored English layouts.