The reason is that in RTL languages you typically mix RTL words with LTR words. In LTR text this is very rare.
For example western brand names or simply just digits, even the arabic versions of digits, are rendered as an embedded LTR word.
The dir="RTL" tag, apart from adjusting alignment, gives a hint whether this paragraph has RTL as a main direction. Otherwise the browser will pick the direction from the first letters in the paragraph (RTLness of a word is an intrinsic property of what unicode character is used). And if those first letters happen to be a western brand name or a digit, the whole sentence would be flipped.
Anyway great article! I cringe when I think about all the bugs and glitches arabic or hebrew readers have to endure in software. Not only in browsers though.
I had never thought about RTL until I started working on a web game with sizeable Arabic user base. It's a bit hard to do right unless you just go transform: scaleX(-1) which is what my predecessor had done.
This is a great guide. My language (Hebrew) is also written from Right to Left so nearly all of these issues are present on sites that I maintain as well.
By far my largest "tech support" issue is helping people _write_ in RTL properly, especially in applications that do not explicitly support RTL. I've written this guide to help, maybe OP will find it useful:
Note that I've found it very helpful to have the LRE and RLE characters right on the keyboard. Linux users who want to add them might find my Unix.SE question helpful:
hopefully, someone else has already implemented this for you (so use libraries for multi-language text layout).
* If you have trouble with RTL in any application - browser, mail client, office suite - be sure to _file a bug_ about it! The developers are often unaware of these issues. Specific link for LibreOffice, where I do a lot of RTL QA: https://bugs.documentfoundation.org/
One thing I think not mentioned, often times when mixing English and Arabic words you need to use ‎ and ‏ html entities to force the words into proper order.
Using dir=rtl or any text alignment css doesn't work, you need to go in and adjust the words individually by wrapping them in those entities.
I would caution shipping that way for most sites for another year or two, though writing that way is good with the PostCSS plugin. Universal support is very new, with the last parts only landing in Safari and Chromium a few months ago, and even most of the features are only dependable back to mid-2019. See https://caniuse.com/css-logical-props, though Firefox 41–65 should also be marked partial <https://github.com/Fyrd/caniuse/pull/6105>.
Lack of browser support is mostly about using -start/-end suffixes, postcss would indeed be useful for this but the majority of the complexity is around requiring 2 different CSS files (ltr and rtl). I’d say with some simple aliasing with postcss you can drop that.
There's a quite interesting article on the directionality preference of UX elements among different RTL user groups which I can recommend: "Towards the Right Direction in BiDirectional User Interfaces"[0].
- "Make sure to set letter-spacing: 0 when working on a multilingual layout" is an advice that's too strong. Letter spacing breaks only with connected scripts, Arabic or Devanagari. (And it's a bug, Arabic script users make use of letter spacing heavily in real life.) Most other scripts - CJK, Cyrillic, Greek, Hebrew, Georgian - will work just fine with letter spacing, and it will have the same meaning as in Latin. But - just as with line height, letter spacing value sometimes needs to be customized.
- You probably don't need to flip the "?" icon for Hebrew users, they don't flip it as in Arabic.
- Arabic letters being rendered over themselves with custom opacity is an unfortunate bug in Webkit. Firefox doesn't have it. But yes, this means that font opacity has to be used sparingly until it's fixed.
A lot of money is spent in design these days, but most of the times nobody cares about the RTL style. In fact, all designs are draw with LTR in mind. Once you have a fairly medium/big app that's designed solely for LTR, the cost of also implementing a RTL rendering is enormous. Every component should be designed twice and implemented with conditional rendering depending on locale.
Isn't there a simpler solution for supporting RTL? Why not render everything LTR and then flip horizontally? Could it work?
The issue is that not everything has to be flipped. Numbers are an example but think about LTR words embedded in a RTL language (some may be urls or email addresses or untranslatable texts).
Designing an HTML page with RTL content is basically a nightmare because the tags are still in English.
Actually some programmers do exactly as you say and flip the view completely, including tags, when they work in a mixed document. I have seen this flow with programmers who use vim in the terminal.
But not, the cost is really not enormous nowadays. It's really a matter of really easy fixes and some testing. Similarly to many other accessibility features the issue is most often ignored completely, however.
There are other problems with big apps. Look at the comments under a YouTube video. YouTube is one of the biggest sites in the world, but it was written and designed by LtR natives. The comments have to support both LtR and RtL languages, but the comment viewing can only support one layout, so the experience is sub-par for RtL. For instance, RtL comments will start at the right and span towards the left where the user's avatar is, whereas Latin comments will sit nicely next to the user's avatar.
Tl;dr: There is no perfect solution when your site has to support both LtR and RtL in the same page at the same time. Someone is going to suffer.
I worked on a game where we shipped that solution. We flipped everything post render but also built some tech to be able to tag certain individual elements that we didn’t want RTL (essentially just flipping those individual elements again).
Alas, RTL is not the only direction a truly multilingual application must support… traditional Mongolian script (‘Bichig’) is written in vertical columns, and is now considered an official script of Mongolia alongside Cyrillic. This means that applications and websites localised for Mongolian may need to support vertical writing (e.g. [0]). At least Bichig is still fairly uncommon in practice.
Vertical text can also be used for Chinese, Japanese and Korean, but I think it's uncommon and used for effect since computer software, including web browsers, has had such bad support for it for so long, and so LTR became the expectation.
It's funny that you almost never see vertical Asian text online, yet it is so common in the real world, especially in print.
It is pretty crazy though that these languages have chosen LtR for their horizontal text, but RtL for vertical text. And when you throw English text into a passage, and numerals too, it gets to be a big fucking mess.
EDIT: This page has an awesome summary of how complicated it gets (e.g. mixing vertical Chinese with RtL Arabic, "vertical" drop-down menus etc):
> It is pretty crazy though that these languages have chosen LtR for their horizontal text, but RtL for vertical text
It’s not actually that crazy: if you rotate RTL vertical text counterclockwise to get text starting from the top of the page, you get LTR horizontal text.
Those arabic texts collapsed on smaller screen, I'm viewing it from mobile.
I don't know much about CSS, but floating elements in my opinion, has always been problematic.
The issue with the default underlining of links sounds like something that the browser ought to be able to do correctly by default.
Does anyone know why it doesn't? Is there a reason for it or is it just one of those backwards compatibility things where changing it would cause more trouble than it is worth?
What a great article, and how valuable to be reminded of the differences in human cultures that we (software developers) so often skip over because so many of us work embedded in anglo-centric contexts. I love being "forced" to realize how my initial response to RTL text ("that's just backwards!") is completely bogus, and there's nothing inherently more or less obvious about LTR or RTL.
We have similar issues in the world of music-related software, where so much is created entirely within the assumptions/defaults of western musical culture; it is gratifying to see that at least for page layout, browsers are doing a better (not perfect, but better) job of covering the whole world.
27 comments
[ 3.0 ms ] story [ 78.7 ms ] threadFor example western brand names or simply just digits, even the arabic versions of digits, are rendered as an embedded LTR word.
The dir="RTL" tag, apart from adjusting alignment, gives a hint whether this paragraph has RTL as a main direction. Otherwise the browser will pick the direction from the first letters in the paragraph (RTLness of a word is an intrinsic property of what unicode character is used). And if those first letters happen to be a western brand name or a digit, the whole sentence would be flipped.
Anyway great article! I cringe when I think about all the bugs and glitches arabic or hebrew readers have to endure in software. Not only in browsers though.
By far my largest "tech support" issue is helping people _write_ in RTL properly, especially in applications that do not explicitly support RTL. I've written this guide to help, maybe OP will find it useful:
https://dotancohen.com/howto/rtl_right_to_left.html
Note that I've found it very helpful to have the LRE and RLE characters right on the keyboard. Linux users who want to add them might find my Unix.SE question helpful:
https://unix.stackexchange.com/questions/674997/new-keyboard...
I'm the maintainer of BiDi Mail UI, an RTL language support plugin for Mozilla Thunderbird:
https://addons.thunderbird.net/en-US/thunderbird/addon/bidi-...
which you may want to check out if you get RTL content in your email (and you're not using webmail).
A few things to note:
* Additional noteworthy RTL languages besides Arabic: Farsi, Hebrew, Urdu, Suret (Syriac).
* The Unicode standard has an official bidirectional algorithm, which is quite involved:
https://unicode.org/reports/tr9/
hopefully, someone else has already implemented this for you (so use libraries for multi-language text layout).
* If you have trouble with RTL in any application - browser, mail client, office suite - be sure to _file a bug_ about it! The developers are often unaware of these issues. Specific link for LibreOffice, where I do a lot of RTL QA: https://bugs.documentfoundation.org/
Using dir=rtl or any text alignment css doesn't work, you need to go in and adjust the words individually by wrapping them in those entities.
[0]: https://arxiv.org/pdf/2101.08070.pdf
- "Make sure to set letter-spacing: 0 when working on a multilingual layout" is an advice that's too strong. Letter spacing breaks only with connected scripts, Arabic or Devanagari. (And it's a bug, Arabic script users make use of letter spacing heavily in real life.) Most other scripts - CJK, Cyrillic, Greek, Hebrew, Georgian - will work just fine with letter spacing, and it will have the same meaning as in Latin. But - just as with line height, letter spacing value sometimes needs to be customized.
- You probably don't need to flip the "?" icon for Hebrew users, they don't flip it as in Arabic.
- Arabic letters being rendered over themselves with custom opacity is an unfortunate bug in Webkit. Firefox doesn't have it. But yes, this means that font opacity has to be used sparingly until it's fixed.
[1] https://docs.microsoft.com/en-us/previous-versions/windows/i...
Isn't there a simpler solution for supporting RTL? Why not render everything LTR and then flip horizontally? Could it work?
Designing an HTML page with RTL content is basically a nightmare because the tags are still in English.
Actually some programmers do exactly as you say and flip the view completely, including tags, when they work in a mixed document. I have seen this flow with programmers who use vim in the terminal.
But not, the cost is really not enormous nowadays. It's really a matter of really easy fixes and some testing. Similarly to many other accessibility features the issue is most often ignored completely, however.
Tl;dr: There is no perfect solution when your site has to support both LtR and RtL in the same page at the same time. Someone is going to suffer.
I agree. Take a look at Figma, it's a fantastic tool, but it doesn't even support writing in RTL languages without using a plugin!
[0] http://mongol.people.com.cn/ (note this only renders correctly in Chrome for me)
It is pretty crazy though that these languages have chosen LtR for their horizontal text, but RtL for vertical text. And when you throw English text into a passage, and numerals too, it gets to be a big fucking mess.
EDIT: This page has an awesome summary of how complicated it gets (e.g. mixing vertical Chinese with RtL Arabic, "vertical" drop-down menus etc):
https://www.w3.org/International/articles/vertical-text/
It’s not actually that crazy: if you rotate RTL vertical text counterclockwise to get text starting from the top of the page, you get LTR horizontal text.
Does anyone know why it doesn't? Is there a reason for it or is it just one of those backwards compatibility things where changing it would cause more trouble than it is worth?
We have similar issues in the world of music-related software, where so much is created entirely within the assumptions/defaults of western musical culture; it is gratifying to see that at least for page layout, browsers are doing a better (not perfect, but better) job of covering the whole world.