Arabic RTL Web Design: 10 Bugs We Fixed and How

Good RTL web design is less about flipping the whole layout and more about the details that do not flip on their own: physical CSS offsets, SVG diagrams, and bidirectional text around numbers, currency and Latin words. Below are 10 bugs we caught while rebuilding noursky.com page by page, each with the exact fix we shipped.

This is a first-hand case study, not a checklist copied from elsewhere. NourSky is rebuilding its own site on a new design system, and every page is built with RTL corrections already in its CSS layer so the Arabic /ar/ version can go live without rework. If you need the same discipline on your own Arabic website for businesses in Saudi Arabia and the UAE, see our web design and UI/UX service.

Why does RTL web design still break in 2026?

Browsers have supported right-to-left layout for years. What breaks is the code people write on top of it.

• Arabic is still rare on the web’s code paths. W3Techs reports that Arabic is used by 0.6% of all websites whose content language it knows (September 2026). Most CSS snippets, component libraries and templates you copy were written and tested in left-to-right only.
• The audience is not rare. DataReportal’s Digital 2026 report counts 34.4 million internet users in Saudi Arabia at the end of 2025, a penetration of 99.0%, and 38.6 million social media user identities.
• The tools are ready. Can I use shows CSS Logical Properties at 97.03% global support (StatCounter data for August 2026). The fix for most layout bugs is available in practically every browser your customers use.

So the gap is not browser support. It is habits: left:, margin-right:, hard-coded SVG coordinates, and the assumption that text order is visual order.

Which CSS layout bugs appear when a page flips to RTL?

Bug 1: Physical inset does not mirror

A badge pinned with left: 24px stays on the left in Arabic, where it now sits on the wrong side of the card and often on top of the heading.

/* Before: stays left in RTL */
.ns-badge { position: absolute; top: 16px; left: 24px; }

/* After: follows the writing direction */
.ns-badge { position: absolute; inset-block-start: 16px; inset-inline-start: 24px; }

MDN describes logical properties as “direction-relative equivalents to their corresponding physical properties.” That one sentence is the whole fix for most offset bugs.

Bug 2: Centring with translate: -50% pulls the wrong way

The classic centring pattern (left: 50%; translate: -50%) mixes a physical offset with a transform. When we converted left to inset-inline-start, the element moved to 50% from the right, but the transform still pulled it left, so it landed off-centre in RTL.

/* After: symmetrical, no transform needed */
.ns-orb { position: absolute; inset-inline: 0; margin-inline: auto; width: 320px; }

Setting both inline insets to zero and letting margin-inline: auto absorb the space centres the element in both directions without any maths.

Why don’t SVG diagrams mirror with dir="rtl"?

Bug 3: <svg> ignores dir

A process diagram with numbered steps and arrows reads 1 → 2 → 3 from left to right. Put it inside an Arabic page and it still reads left to right, because SVG coordinates are absolute. dir on the parent does nothing to them.

Our fix was to redraw each directional diagram with mirrored coordinates (x becomes viewBox width minus x) and to flip the sweep-flag of every arc in the path data, because an arc that curved clockwise in English must curve the other way in the mirror image. A CSS scaleX(-1) looks tempting, but it also mirrors any text and icons inside the drawing.

Bug 4: text-anchor="end" does not mean “right”

Inside an RTL drawing, text-anchor="end" anchors to the end of the text’s own direction. For Arabic labels, the end is on the left. We stopped reading start/end as “left”/”right” and checked each label’s position in a rendered screenshot instead.

Why do numbers, prices and ranges flip inside Arabic text?

This is where most Arabic websites look broken to native readers. The Unicode Bidirectional Algorithm treats characters in classes, and we met three different classes, each needing a different fix.

Bug 5: Neutral characters flip ranges (“3–5” shows as “5–3”)

The en dash and the multiplication sign are neutral: they take their direction from the text around them. Inside an RTL paragraph, “3–5 days” can render as “5–3”.

.ns-range { unicode-bidi: plaintext; }

MDN explains that plaintext makes the element’s directionality “calculated without considering its parent bidirectional state.”

Bug 6: Weak characters move the currency sign (“$75,600” shows as “75,600$”)

The dollar sign is a weak character, so a price can lose its sign to the wrong side.

.ns-price { unicode-bidi: isolate; direction: ltr; }

isolate makes the parent treat the price as a single object, “like an image”, in MDN’s words, and direction: ltr fixes the order inside it.

Bug 7: A Latin segment at the end of an Arabic sentence makes the full stop jump

When an Arabic sentence ends with a Latin term such as “WhatsApp Business API”, the final full stop can appear on the far left of the line. The fix is markup, not CSS:

<p>نربط الموظف الذكي عبر <span dir="ltr">WhatsApp Business API</span>.</p>

W3C’s guidance supports this approach: when browsers encounter the dir attribute on an element, they “(directionally) isolate the text inside the element from the text surrounding it.”

Bug 8: Token names and hex values flip too

Anywhere a page displays a design token such as --ns-v-600 or a hex colour value, the leading -- or # is a neutral character, so inside an RTL paragraph it jumps to the wrong end of the code. The rule we adopted: every Latin code segment on an Arabic page sits inside an isolating wrapper.

A note of honesty on bugs 5 and 6: MDN warns that unicode-bidi is intended for DTD designers and that authors “should not” override it. W3C says the same in different words: “You should always use dedicated bidi markup to describe your content, where markup is available.” Treat the CSS values as a targeted tool on specific components, and prefer dir or <bdi> wherever you author the text.

Which non-RTL bugs surfaced in the same bilingual build?

These two are not RTL bugs, but they appeared in the same verification passes and would have shipped to both languages.

Bug 9: Column percentages that forget the gaps

Columns summing to 90% plus three 40px gaps inside a 1112px container need 1000.8 + 120 = 1120.8px. That overflows by 8.8px, and the last column drops to a new line. In Elementor we also removed width: 0% keys, which Elementor applies literally and which collapse columns; flex-grow and flex-shrink do what “auto width” was supposed to do.

Bug 10: Elements stuck at opacity: 0 after fast scrolling

Reveal animations built on IntersectionObserver can miss elements when the user scrolls fast, because entries get merged. Those sections stayed invisible. We added a debounced sweep that reveals anything already inside the viewport, and all motion respects prefers-reduced-motion.

Summary: the 10 bugs and their fixes

What we’ve seen in our projects

Every one of these bugs was caught by a gate, not by eye. On the noursky.com rebuild, no page moves forward until it passes the same checks: render at 1440×1000 and 390×844 with no horizontal overflow; zero JavaScript errors; design tokens confirmed as actually injected; stepped scrolling so every IntersectionObserver fires, with zero elements left at opacity 0; a programmatic WCAG 2.1 AA contrast audit; and structural checks on the Elementor JSON, which is generated by a script that reads the built page’s DOM so the page and template cannot drift.

The lesson we took from it: RTL quality is a testing problem more than a design problem. A designer can approve a mirrored mockup, but a range, a price or an arc in an SVG only breaks when real content meets the real bidi algorithm in a real browser. For the Elementor side of the same rebuild, see Case Study: Rebuilding noursky.com on Elementor Containers.

FAQ

Is adding dir="rtl" to the <html> tag enough for an Arabic website?

No. It flips text flow and flex order, but physical CSS offsets, transforms, SVG coordinates and mixed-direction text around numbers, prices and Latin words still need their own fixes.

Should I use CSS unicode-bidi or HTML dir to fix flipped text?

Prefer HTML markup (dir, <bdi>) wherever you author the text, as W3C recommends. Use unicode-bidi narrowly on components such as price or range chips, knowing MDN advises authors against overriding it broadly.

Do CSS logical properties work in all browsers?

Almost all. Can I use reports 97.03% global support for CSS Logical Properties based on StatCounter data for August 2026.

Sources

• Usage statistics of Arabic for websites — W3Techs, September 2026
• Digital 2026: Saudi Arabia — DataReportal
• CSS Logical Properties — Can I use (StatCounter data, August 2026)
• CSS logical properties and values — MDN
• unicode-bidi — MDN
• Inline markup and bidirectional text in HTML — W3C Internationalization
• CSS vs. markup for bidi support — W3C Internationalization