This is indeed an easy way to fix text rendering in your inputs and textareas. However, you'll also need to do the same for elements that render the submitted text. And once you encounter bidirectional text (e.g. an English product name within an Arabic paragraph), that opens up another whole can of worms...<p>Note also that there's currently a regression in Chrome that affects how RTL text is rendered in inputs with dir='auto'. They just shipped a fix though so it should be included in the next release.
MDN always comes to the rescue: <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/dir" rel="nofollow noreferrer">https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...</a>
> As someone living in the bubble that is the United States, it can be hard to think externally. But every so often I am reminded there is a world outside of my own.<p>There is a world outside the US but you don't <i>have</i> to support it, depending on what your site does. I'm not american. I'm not even a native english speaker. And 99% of the sites I go to are perfectly fine if they don't allow neither usernames nor posts containing RTL characters.<p>If it's not solved at the browser or OS level, I've got about zero obligation to support this.<p>And, no, this is not about oppressing minorities.
> <i>The first results page of Google never lies...</i><p>I have something to tell you that will help you solve your problem, but you should sit down first, because it's probably going to make you sad...
Sadly, both the website and the linked codepen render the source quite poorly. The period is in the wrong place! The rendered HTML is fine.<p>I assume this is just the Unicode bidirectional algorithm failing, as it is wont to do. I imagine that a special cased algorithm that understood that HTML tags (the stuff between < and > inclusive) should render as atomic things, internally LTR, but without imposing their direction on surrounding characters.<p>In this example, the algorithm should be willing to switch direction in the middle of the sequence “.<“
On a related note, support for "logical properties/values"[1] has become mature in recent years. These are alternatives to directional-based properties (top/left/bottom/right) which are adaptable to switching content/text directions.<p>[1] <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_logical_properties_and_values" rel="nofollow noreferrer">https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_logical...</a>
Uh.<p>If I search for textarea and BiDi text, in pretty much all variations I can think of <a href="https://www.w3.org/International/talks/1602-oman" rel="nofollow noreferrer">https://www.w3.org/International/talks/1602-oman</a> is one of the top links.<p>And right in there, the "What if you don't know the direction in advance" section, <a href="https://www.w3.org/International/talks/1602-oman/#advance" rel="nofollow noreferrer">https://www.w3.org/International/talks/1602-oman/#advance</a><p>I assume the problem is that the author doesn't really know the space, and so didn't even know that "BiDi" is the right search term here. (For "bi-directional text", since you don't want to specify a writing direction)<p>I don't even fault them for thinking "the results are wrong" - they aren't, if you search for RTL they're the right answer. But you won't know that until you know the space a bit better. This highlights a problem with relying on the Internet for answers - it doesn't know what you don't know. Sit down with anybody who's dealt with BiDi for a while, and one of their first questions will be "Do you mean RTL or BiDi"?<p>So, if you can, ask people, not software. Especially if you don't know the space.
I'd also add a link here to `dirname` which is an interesting one for including text directionality of text input in form submissions: <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/dirname" rel="nofollow noreferrer">https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...</a>
Yeah, as far as I'm concerned, this is a deficiency of language detection. Specific types of input types should auto rtl based on the user agent's locale usage.<p>A number of other automatic behaviors exist simply when you change your primary language, and this is one of them that should change by default. You'll know this by experience if you speak another language and occasionally flip your primary language over. All the sites you browse start respecting your lang and locale settings.<p>Other technical or format-specific inputs should retain their relevant direction.
This is good advice, but the problem is that there is so much good advice about webdev (and everything) that one tends to form a FIFO queue in one's brain such that the advice is inevitably lost.
There is also this shortcut of ctrl+shift+x to switch to RTL. Which is really funny when you do it on Twitter since it flips the entire user interface.
I find it rather baffling that people don't seem to spend any time reading specs. I haven't done anything even remotely serious in HTML since about 2003, and I know about (and have used) the dir attribute.<p>it is one of maybe 12 global non-event attributes.
OK, now does that work OK for sites that are vertical input? ;)<p><a href="http://khumuunbichig.montsame.mn/index.php?command=newsall&readnews=1170" rel="nofollow noreferrer">http://khumuunbichig.montsame.mn/index.php?command=newsall&r...</a>
Why in 2023 is this still an issue?<p>Frameworks and browsers should be designed that if you totally ignore rtl support, the browser/framework just does some usable default.<p>Just like if you don't set a font size, the browser chooses one for you. Or if you don't specify the background color, one is chosen for you.
<i>dir</i> is a global attribute that can be set on any HTML element:<p><a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/dir" rel="nofollow noreferrer">https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...</a><p>What I don’t understand is why <i>dir="auto"</i> isn’t set as the default value, allowing browsers to choose text direction based on the <i>lang</i> attribute or the text content.
To the people wondering why this is still an issue: Most tech is very US- or west-centered. My name contains an Umlaut (ü), which causes me trouble much more often than should be the case. A colleague of mine even changed their name by substituting ä foe ae, to avoid this issue. We still have the benefit of mostly ASCII names mind you. It can get a lot worse.
This seems like an odd thing for developers to have to do.<p>Why isn't it done by default by the browser? What <i>is</i> the browser default? (Strangely, MDN docs don't seem to indicate.) And if it's not already this, why not?
It is so ridiculous that this doesn't happen by default. Normally I'm against breaking changes, but in this case? The default is dumb and wrong. Inclusivity should always be the starting point, and manual hacks should be the exception.