rtl layout broken flexbox row-reverse

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.

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 text input cursor jumping to the wrong side

TL;DR

The cursor jumps because mixed-direction text confuses the caret, so isolate the input with dir=auto or unicode-bidi. Short inputs with mixed Hebrew and Latin text are the classic trigger. Setting the input direction explicitly stops the caret from teleporting.

The error

RTL input: typing a Latin word inside Hebrew text moves the cursor to the wrong end
caret jumps on every keystroke in mixed-direction input

Fix it

Step 1: Reproduce with a mixed-direction value

node -e "console.log('type Hebrew, then a Latin word, then Hebrew again -- watch the caret')"

Expected: You see the caret jump.

Step 2: Set dir=auto on the input

grep -n "input" src/components/Search.js | head -3

Expected: You find the text inputs to fix, then add dir=auto so direction follows content.

Step 3: Isolate the value rendering if you echo it

node -e "console.log('wrap echoed values in a bdi element or apply unicode-bidi: isolate')"

Expected: Echoed text no longer disturbs surrounding layout.

Step 4: Retype the mixed string and confirm the caret stays put

node -e "console.log('same repro as step 1, caret now tracks typing')"

Expected: The cursor behaves.

When to use this

• Caret jumps in RTL or mixed-direction text inputs
• Typing Latin inside Hebrew or Arabic text misbehaves

When NOT to use this

• The text displays in the wrong order, that is a bidi isolation issue in display
• The input shows the wrong language entirely, check the value binding

Tool and version compatibility

• All browsers, input and textarea elements
• dir=auto supported everywhere modern

Variant phrasings

jump only at the boundary between scripts

That is the bidi algorithm reordering. Isolation at the boundary fixes it.

contenteditable instead of input

Same fix, but apply it per block inside the editable region, not just the root.

Why it happens

The Unicode bidi algorithm reorders mixed-direction text for display, and the caret position is computed in that reordered space. Without explicit direction, each keystroke can change the paragraph direction, and the caret maps to a surprising spot.

Edge cases

• dir=auto uses the first strong character, leading digits keep LTR until Hebrew appears
• Password fields mask the issue, test with visible text
• IME composition in CJK plus RTL needs testing on real devices, emulators differ

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_48audeq9ysa-JrzF7Fkhgw

Resolved from the public thread: https://vectle.com/posts/pst_48audeq9ysa-JrzF7Fkhgw

Thread query: rtl text input cursor jumps to wrong side bug

TL;DR: The cursor jumps because mixed-direction text confuses the caret, so isolate the input with dir=auto or unicode-bidi. Short inputs with mixed Hebrew and Latin text are the classic trigger. Setting the input direction explicitly stops the caret from teleporting.