I’m confused. Why is that not the default? Do web browsers for people configured to use RTL languages really default to LTR text input?
I honestly don’t know how people in these locales use computers. I had fun recently when someone from Israel sent me a PowerPoint template. First, it turns out the PowerPoint hides the button to toggle the writing direction unless you have both RTL and LTR locales installed (so I couldn’t change it without installing extra system-wide components but they could). Then it turned out that the keyboard shortcuts for text navigation actually did work but they moved the visual indicator to the wrong end until you started typing (and then it flickered between the two locations). And that’s in one of the flagship applications from the dominant desktop OS vendor, I have no idea how much worse it is in more niche things.
If I worked on mass-market GUI applications I think that I’d live in perpetual fear of some nice folks from Mossad dropping by for a friendly 3am chat.
To solve this problem, that spec would need a rule that the directionality of text-type input elements whose dir attribute is not in a defined state should use the algorithm for dir="auto".
I don’t know why the spec has no such rule. The spec already says the directionality of <input type="telephone"> will default to LTR even on RTL pages, so some edge cases were considered. Perhaps when the spec was written, there were concerns about performance of scanning each string for a directionality-indicating character?
Firefox is enormously configurable, so I expected to see a toggle somewhere in about.config, but there doesn’t seem to be an option to do this exactly.
PSA: Don’t just blindly add attributes without knowing what they’re supposed to do and testing them. This is like people who use ARIA roles instead of the semantically correct tag.
Yes, if the whole site is RTL, then the individual inputs are RTL as well. The recommendation to set dir="auto" is aimed at authors of LTR websites with some users who write in RTL languages, or, conversely, authors of RTL websites with LTR users.
For example, a site for managing a library of books might have its navigation and documentation written in LTR English, but might accept book titles in RTL Arabic. If the field to enter a book title is just an <input>, the typed Arabic book title will be LTR in the input field. <input dir="auto"> allows the field to display either English or Arabic book titles with correct directionality.
Even if the site shows text with the correct directionality in the input field, it would still need to show the rendered book title correctly everywhere else it is used (such as an h1 or a li). I don’t know much about what, if any, extra work is needed for most usages. The one thing I know is that when quoting an arbitrary book title in the same sentence as LTR text, the site should use the <bdi> element, but I think most sites insert user content in their own block elements, where <bdi> is unnecessary.
I’m confused. Why is that not the default? Do web browsers for people configured to use RTL languages really default to LTR text input?
I honestly don’t know how people in these locales use computers. I had fun recently when someone from Israel sent me a PowerPoint template. First, it turns out the PowerPoint hides the button to toggle the writing direction unless you have both RTL and LTR locales installed (so I couldn’t change it without installing extra system-wide components but they could). Then it turned out that the keyboard shortcuts for text navigation actually did work but they moved the visual indicator to the wrong end until you started typing (and then it flickered between the two locations). And that’s in one of the flagship applications from the dominant desktop OS vendor, I have no idea how much worse it is in more niche things.
If I worked on mass-market GUI applications I think that I’d live in perpetual fear of some nice folks from Mossad dropping by for a friendly 3am chat.
I can at least confirm that this browser behavior matches the HTML spec:
dirattribute inherits its parents directionality.htmlelement is LTR by default.To solve this problem, that spec would need a rule that the directionality of text-type
inputelements whosedirattribute is not in a defined state should use the algorithm fordir="auto".I don’t know why the spec has no such rule. The spec already says the directionality of
<input type="telephone">will default to LTR even on RTL pages, so some edge cases were considered. Perhaps when the spec was written, there were concerns about performance of scanning each string for a directionality-indicating character?Firefox is enormously configurable, so I expected to see a toggle somewhere in about.config, but there doesn’t seem to be an option to do this exactly.
PSA: Don’t just blindly add attributes without knowing what they’re supposed to do and testing them. This is like people who use ARIA roles instead of the semantically correct tag.
It is shocking to me that user agents don’t handle this correctly.
Exactly. That’s the whole point of user agents!
I guess I shouldn’t be surprised, still less shocked, at user agents intentionally and aggressively not acting as agents for the user. Sigh.
I’m using, e.g.:
All elements seem totally fine for RTL? If I add
dir="auto"to an<input>field, it makes it LTR again. What am I missing?Edit: I was surprised how easy it was to fix this, but of course it wouldn’t be the first time that the easy solution is the wrong solution.
Yes, if the whole site is RTL, then the individual inputs are RTL as well. The recommendation to set
dir="auto"is aimed at authors of LTR websites with some users who write in RTL languages, or, conversely, authors of RTL websites with LTR users.For example, a site for managing a library of books might have its navigation and documentation written in LTR English, but might accept book titles in RTL Arabic. If the field to enter a book title is just an
<input>, the typed Arabic book title will be LTR in theinputfield.<input dir="auto">allows the field to display either English or Arabic book titles with correct directionality.Even if the site shows text with the correct directionality in the
inputfield, it would still need to show the rendered book title correctly everywhere else it is used (such as anh1or ali). I don’t know much about what, if any, extra work is needed for most usages. The one thing I know is that when quoting an arbitrary book title in the same sentence as LTR text, the site should use the<bdi>element, but I think most sites insert user content in their own block elements, where<bdi>is unnecessary.Thanks for the extensive explanation! Makes sense now :)
It wouldn’t take much to create a browser plugin that did this automatically for you; I would think one would already exist