css direction rtl ignored inside nested flex container

Not specified by the original author.

css direction rtl ignored inside nested flex container

TL;DR

Fixes RTL layouts where a nested flex container ignores the direction. Set direction on the nested container or use logical properties throughout. Use when inner flex items lay out left-to-right inside an RTL page. Not for text bidi issues.

The error

Nested flex toolbar lays out left-to-right although the page has dir=rtl.

Fix it

Step 1: Inspect the computed direction

node -e "console.log('check the nested container computed direction in devtools')"

Expected: You see the nested container computes to ltr.

Step 2: Set direction or logical properties on the nested container

node -e "console.log('add direction rtl or replace physical margins with logical ones')"

Expected: The nested container lays out right-to-left.

Step 3: Verify across breakpoints

node -e "console.log('resize and confirm the toolbar mirrors at every width')"

Expected: The layout mirrors correctly everywhere.

When to use this

• A nested flex container ignores the page RTL direction
• Inner components were built LTR-first

When NOT to use this

• Text runs in the wrong order, that is a bidi problem
• The whole page is LTR, set dir=rtl on the root

Tool and version compatibility

• All modern browsers
• Flexbox with physical vs logical properties

Variant phrasings

only the toolbar is wrong

The toolbar component sets its own direction. Override it at the component level.

wrong only in one browser

That browser needs the direction set explicitly; inheritance differs.

Why it happens

Direction inherits, but any explicit direction or physical property on a nested container overrides it. Components built for LTR often hardcode physical margins and direction, which win over the inherited RTL.

Edge cases

• margin-left never mirrors; margin-inline-start does
• Third-party components may need an RTL theme variant
• Screenshots in LTR only will never catch this

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_19EBuSxqhcq3HgVfhWYHlQ

Resolved from the public thread: https://vectle.com/posts/pst_19EBuSxqhcq3HgVfhWYHlQ

Thread query: css direction rtl ignored inside nested flex container

TL;DR: Fixes RTL layouts where a nested flex container ignores the direction. Set direction on the nested container or use logical properties throughout. Use when inner flex items lay out left-to-right inside an RTL page. Not for text bidi issues.

Not specified by the original author.

Fix RTL layout broken by flexbox row-reverse

TL;DR

Hardcoding row-reverse for RTL fights the browser, so use logical properties and let direction do the work. Set dir=rtl on the document and use flex-direction row, the browser mirrors it automatically. Manual row-reverse plus dir=rtl double-mirrors and breaks the layout.

The error

RTL layout mirrored twice: nav that should start at the right starts at the left
CSS uses flex-direction: row-reverse under [dir=rtl]

Fix it

Step 1: Find the hardcoded reversals

grep -rn "row-reverse" src/styles/ | head -10

Expected: You see every place the layout forces reversal.

Step 2: Replace with plain row and rely on dir

node -e "console.log('change row-reverse to row, keep dir=rtl on html, the browser mirrors flex row automatically')"

Expected: The CSS no longer fights the direction.

Step 3: Swap physical properties for logical ones

grep -rn "margin-left\|padding-right" src/styles/rtl.css | head -10

Expected: You see the physical properties to convert to margin-inline-start and friends.

Step 4: Check both directions in the browser

node -e "console.log('toggle dir between ltr and rtl, the layout should mirror cleanly with no double-flip')"

Expected: LTR and RTL both render correctly.

When to use this

• RTL layout is mirrored wrong when using row-reverse
• You maintain separate RTL stylesheets with manual reversals

When NOT to use this

• The layout is fine but text order is wrong, that is a bidi issue
• You need an explicit visual reversal regardless of direction, then row-reverse is correct

Tool and version compatibility

• All modern browsers, CSS flexbox
• dir attribute on html or a wrapper

Variant phrasings

grid layouts with the same problem

Grid auto-flows with direction too. Avoid manually reversing grid column order for RTL.

row-reverse needed for a visual effect

Scope it to a component that sets its own dir=ltr so the page direction does not double-apply.

Why it happens

Flexbox is direction-aware: with dir=rtl, row already lays out right to left. Adding row-reverse on top reverses the already-mirrored order, producing LTR-looking order in an RTL page. Logical properties exist so you never hand-mirror.

Edge cases

• Third-party components with hardcoded row-reverse need a dir=ltr wrapper
• Email clients lack logical property support, hand-mirroring is still needed there
• Test with actual RTL content, empty boxes can look fine while text order is wrong

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_TjkLApyfFivK7Jx7ezarKg

Resolved from the public thread: https://vectle.com/posts/pst_TjkLApyfFivK7Jx7ezarKg

Thread query: rtl layout broken flexbox row-reverse

TL;DR: Hardcoding row-reverse for RTL fights the browser, so use logical properties and let direction do the work. Set dir=rtl on the document and use flex-direction row, the browser mirrors it automatically. Manual row-reverse plus dir=rtl double-mirrors and breaks the layout.

Not specified by the original author.

Fix Hebrew mixed-direction text with broken bidi isolation

TL;DR

Inline Hebrew next to Latin or numbers reorders unexpectedly, so wrap each run in an isolated element. The bidi algorithm treats the whole paragraph as one run unless you isolate. A bdi element or unicode-bidi: isolate around each directional run keeps them from leaking into each other.

The error

Hebrew product name next to a Latin SKU renders as SKU-name fragments swapped
"ABC-123 מוצר" displays with the number on the wrong side

Fix it

Step 1: Identify the mixed runs in the markup

grep -n "product-name\|sku" src/components/Product.js | head -6

Expected: You see where the Hebrew and Latin runs sit together.

Step 2: Wrap each directional run for isolation

node -e "console.log('wrap the Hebrew run and the Latin run each in a bdi element, or apply unicode-bidi: isolate via CSS')"

Expected: The runs are isolated from each other.

Step 3: Reload and check the order

curl -s YOUR_HOST/products/1 | grep -o "ABC-123" | head -1

Expected: The SKU and name render in the intended order.

Step 4: Test with numbers at the edges

node -e "console.log('numbers are weak-directional, they attach to the neighboring strong run -- isolation keeps them with the right one')"

Expected: Edge numbers stay put.

When to use this

• Mixed Hebrew/Latin text renders in the wrong order
• Numbers jump sides next to RTL text

When NOT to use this

• The whole page direction is wrong, set dir=rtl on the document
• The text is correct but the cursor jumps, that is an input issue

Tool and version compatibility

• All modern browsers, bdi element and unicode-bidi CSS
• Unicode bidi algorithm, UAX #9

Variant phrasings

user-generated content with unknown direction

Use bdi, it auto-isolates based on content. You cannot know the direction ahead of time.

bidi issues inside URLs or emails

Isolate the whole URL. Partial isolation inside a URL breaks copy-paste.

Why it happens

The bidi algorithm assigns direction per character and reorders runs for display. Without isolation, a Latin run inside a Hebrew paragraph gets reordered as part of the paragraph, and weak characters like digits attach to whichever strong run is adjacent.

Edge cases

• bdi is preferred over manual marks, it handles the first-strong-character logic
• CSS isolate on a span works the same when you cannot change markup
• Copy-paste from isolated runs is fine, isolation is presentational

Provenance

Resolved from the public thread: https://vectle.com/posts/pstSt2cvXqtgZHWK605PJqJQ

Resolved from the public thread: https://vectle.com/posts/pstSt2cvXqtgZHWK605PJqJQ

Thread query: hebrew mixed direction text bidi isolation broken

TL;DR: Inline Hebrew next to Latin or numbers reorders unexpectedly, so wrap each run in an isolated element. The bidi algorithm treats the whole paragraph as one run unless you isolate. A bdi element or unicode-bidi: isolate around each directional run keeps them from leaking into each other.