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...
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.
Adapting your UI to RTL localization is a much more difficult proposition, but what well-placed dir="auto" can do is prevent an LTR-language UI from falling apart in the face of RTL user data (looking at you Gmail).
> 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.
There is a world outside the US but you don't have 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.
If it's not solved at the browser or OS level, I've got about zero obligation to support this.
I remind myself that whenever I'm working on a solo project and think about supporting other languages. A quick google search shows there are 840M English speakers. I'm just one man! Building something that only 1/10 of the world can use still seems pretty good.
If you want to expand your audience to support more of the world, that is totally cool, but as you say, there is no obligation to do so.
> 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...
I think you are responding to this sentence read literally:
> The first results page of Google never lies, so I thought this was just inherently a problem that required direct intervention, and so was never quite able to prioritize it (so much for my moral high ground).
but I'm almost 100% confident that it was meant with the sarcasm that it deserves, as indicated by the later sentence:
> Google has been lying to us about RTL support in inputs.
> Google has been lying to us about RTL support in inputs.
Whatever the users of the internet prioritized as important showed up first. There is no lying. Google search results and now ChatGPT/AI responses are pretty much a reflection of the information base provided to it. Biases, inaccuracies, et al. Its a weighted mirror on humanity (where some cultures/languages/regions have contributed more data and hence have a higher weight - like English speaking corpus).
> Whatever the users of the internet prioritized as important showed up first. There is no lying. Google search results and now ChatGPT/AI responses are pretty much a reflection of the information base provided to it. Biases, inaccuracies, et al. Its a weighted mirror on humanity (where some cultures/languages/regions have contributed more data and hence have a higher weight - like English speaking corpus).
It is certainly reasonable to argue about whether "lying" requires intent, but I think that it is usually agreed that "lying" in this context means "presenting false information without indicating that it is false."
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.
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.
In this example, the algorithm should be willing to switch direction in the middle of the sequence “.<“
The Unicode bidi algorithm isn't failing here, it's working as designed. The source code snippet has base direction LTR, but has mixed-direction content because of the Hebrew text. Punctuation marks have weak directionality, so the period shows up at the end of the RTL run. Since the base direction is LTR, the 'end' of the RTL run means the right side.
If you want to force mixed-direction content to render correctly, you often need to insert bidirectional control characters to specify where a certain directional run begins/ends. That doesn't make sense to add in this case, though, because it would mess up the rendering in the actual input example.
I would argue that it’s failing and working as designed.
Perhaps a syntax highlighter could learn to insert “first strong isolate” and “pop directional isolate” and to also enforce that content leaves the stack alone?
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.
These have been standard on mobile platforms for a long time now (e.g. "leading" and "trailing" on iOS), good to see them making their way onto the web. They make building a language-agnostic UI a much more reasonable task.
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)
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"?
So, if you can, ask people, not software. Especially if you don't know the space.
At what point is someone 'allowed' to criticize an author's approach and point out another that would have made their struggle shorter?
Accusations of gatekeeping should be accompanied with evidence of malice if they are to be taken seriously. Correcting (or, more like augmenting) someone speaking authoritatively on something is not gatekeeping. Also, gatekeeping has a social value, when used at the right time in the right circumstances. Bouncers literally keep the gate at a venue. Relevant experience in a given field is often necessary to have high-level (or in-depth) conversations about something within said field. If you have a group of people comparing sorting algorithms and some dude rolls up to offer his opinion without even understanding what a sorting algorithm is, would you 'appreciate' their uninformed and uninsightful take on something, lacking the shared knowledge of your group? Or would you rather clarify where the guy is wrong, refer him to a resource, and tell him to come back when he knows a bit more about what he's talking about?
Don't get hung up on details here. It's not about sorting algorithms. It's about 'deep knowledge' in a field needing to be shared to elevate discussion, for lack of a better descriptor.
Gatekeeping becomes a problem when it's mean, when it isn't helping anyone learn more, and when it's not protecting a culture or improving discussion in any meaningful way. Helping newbies learn from better sources is arguably gatekeeping -- it's just not considered harmful.
Now if we could do something about baseless accusations...
Here's another way groby_b could have said the same thing:
"I spend a lot of time designing UI for international users. In these circles, the issue you're talking about is referred to as 'BiDi' text input. If you would like to know more, ping me! Sometimes Googling isn't fruitful if you don't already know the lingo."
Maybe this sounds better to you, too. If not, maybe I'm wrong. It happens a lot. :-)
Yeah, I agree (with you) that your top-level comment is very very correct, and contributes a fantastic point.
And I agree (with some commenters) that the "Uh" makes it look way worse than it would otherwise. :) I learned something from both your comment and from the criticisms. Yay.
--
Though I think "you shouldn't rely on the Internet" is not quite summarizing it exactly correctly (not a complaint about the original comment, just trying to improve on the summary). It's not "relying on the internet" that's the problem, it's some weird conjunction of a few things that are each fine. I will try to expand, fumblingly.
(1) Obviously you could have a conversation with an expert-in-the-space over the internet, so clearly it's not the internet that's the problem. (2) Obviously you can get good results off Google, for example by googling "textarea bidi", so it's not Google that's the problem. And, heck it, compared to not having an internet to search, the internet does a lot to reveal the hidden complexity that we wouldn't otherwise even be aware of.
So we could propose that the problem is non-experts doing things (i.e. we could encourage gatekeeping), but wait, that's not right either, because that would imply that Mo shouldn't have created Standard Notes until they were an expert in all relevant things (which turns out to include something something multilingual something), and clearly if Standard Notes wasn't delivering great value without that expertise, then they wouldn't be getting "requests to add right to left language support". So obviously Mo had more than enough expertise to do what they did.
I dunno. I dunno what the pithy version of the takeaway could be. We might just have to settle with the longer version from your original comment.
"[Neither you, nor google, knows] what you don't know. ... So, if you can, ask people, not software. Especially if you don't know the space."
I think it was the "uh." :-) If I read it without it, it's not so bad. And I know we all dash off comments quickly sometimes. Apologies if I overreacted.
While that may be a saner default for user input form controls which are kind of a separate document, it would be a very bad default for every element. It is also probably not the best default if you know the user is inputing content in a specific language (but of course better than getting it wrong).
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.
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.
Other technical or format-specific inputs should retain their relevant direction.
I suppose you’re talking about browser behavior, because I’ve yet to see a website that respects my language headers instead of assuming the language I speak based on geo-IP
The other common situations are explicitly choosing my language in a drop down menu every time I visit it, or some user preferences thing. Often sites come up with a hybrid approach and I get mixed language/locale content.
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 used to work on web RTS game and one of the FE guys before my time had used scaleX(-1) for virtually every RTL case. First he flipped the viewport, then flip back everything that shouldn't have been flipped.
I threw pretty much all his html, CSS and JS once I was allowed to render most of the game with WebGL
It's weirder even: Pressing ctrl-shift-x when the input field is highlighted inserts "rtl", then pressing it again flips the entire user interface but not the input field.
RTL has really bad support on the web, and RTL folks are constantly having to input into and read RTL text in interfaces designed for LTR which makes things really awkward to read.
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.
it is one of maybe 12 global non-event attributes.
Not OP, but… the article title (correctly for this purpose) uses standard quote characters, so you could presumably copypasta the attribute straight from the title into HTML. The title as currently posted on HN uses curly quotes, so copypasta from there would produce invalid HTML. It’s a weird nitpick, for sure! Approximately nobody is going to copypasta straight from a substring of an HN title/link into HTML, of course. But it is technically both correct and pertinent.
I mean Safari and Firefox only recently (2021) got datetime / datetime-local input support and afaik they still aren’t feature complete (html5). Date pickers have been one of the most popular / important widgets in Javascript for like the last 20 years or so. The only reason edge has it is because it’s backed by chrome (IE / MS was notorious for foot dragging in the space).
No. Two problems with your ask is "all browsers" and "no usability quirks", which is never the case. In general compatibility can be found here: https://caniuse.com/?search=datetime-local
It works that way if you correctly use modern features of CSS/HTML. This is just one of those features. It’s very difficult to correctly update the web platform because backward compatibility is so important for the most widely used programming platform in the world.
Lol it's funny to summarize this discussion as: "we don't want to make a (seemingly) positive change because too many people rely on us to live in their 'backwards' ways".
Thats fine, but then you say "we're going to make a new html6, and if you put DOCTYPE html6 at the start of your page, then legacy behaviours like that will be dropped and we'll start doing the right thing by default"
And there's absolutely no problem with it. Except that it won't happen due to the standard bodies losing face after they made a lot of noise with their decision that HTML 5 was the one true standard that would never get replaced.
Microsoft also acted like Win10 would be the last one, and here we are with Windows 11. I doubt anyone gave a damn about that. Normies don't have values when faced with not getting their shiny.
What should be more damning, IMO, is that there are barely any grassroots or community members on WHATWG, who has acted like they are more important than W3C. Both have drafted and approved of things that have damaged the Web. I am looking forward to the inevitable protocol split between "linkable documents" and "apps in a common virtual machine". The complexity desired from web app authors is directly opposed to the sort of things that plain HTML and CSS were doing 15-20 years ago.
It'd be nice if Google and friends just worked on the app side of things, on their own protocol, instead of commandeering the Web.
It might totally make sense for user input controls to be a separate directionality context from the rest of the document by default.
But in general, i don't think there is a right answer that works in all cases. The existing defaults (bidi algorithm) do make a best guess that is probably the best guess possible.
What I don’t understand is why dir="auto" isn’t set as the default value, allowing browsers to choose text direction based on the lang attribute or the text content.
It affects float direction. Imagine the browser detecting Arabic text and suddenly all your float lefts are floating right. Switching it from one side to the other will completely break a lot of layouts, particularly older ones.
Good thing that there is no reason anymore to use float to hack page styles, instead of floating objects within your text. So that switching the direction is the correct thing to do with reasonably placed float out there.
This should be the operating systems problem to solve not developers of every website ever. Same with spellchecking, emojis, copy/paste etc.
From from your mouth to God's ear.
I wish every program would default to system-wide settings. But unfortunately, too many do their own things.
Why does Microsoft Office need a separate dictionary from the rest of my computer? Why does Wrike intercept ⇧⌘N? Why doesn't Adobe Photoshop use ⌘, for preferences like every other Mac program for the last 38 years?
It's the thousand little annoyances users run into every day that make them hate computers.
To be fair, it also wouldn't make sense for Office to have different dictionaries between its Mac and PC (and web) versions. So one or the other has got to give.
Users want OS's to be consistent across apps, but users also want apps to be consistent across OS's. And so the reality is each feature is going to be decided on a case by case basis and the end result will be somewhere in the middle.
it also wouldn't make sense for Office to have different dictionaries between its Mac and PC (and web) versions.
Why?
99.9% of people using Microsoft Office are using it on one computer. I'd wager the majority of those people aren't using only Microsoft Office and nothing else.
If Office used the system dictionary, then people's added words would exist in every application they use, and not just every application except Office.
> 99.9% of people using Microsoft Office are using it on one computer. I'd wager the majority of those people aren't using only Microsoft Office and nothing else.
If you step outside the tech bubble, yoı'll see Microsoft Office is actually used to do, you know, office work quite extensively. If you work in a big enough company, it is probably an Excel file transferred from your company to the bank that paid your salary. This is its major purpose and where it is being used predominantly. As you can guess, those files are being shared accross computers that run completely different OSes.
Word is a word processing program. Its job is provide a consistent experience in paper-form document generation. Its job is to be useful and consistent regardless of the underlying system. It gives you suggestions based on its own dictionary that has extra metadata. I doubt that your system has the exact metadata it has.
It could be a reasonable ask to support injecting words from the system user dictionary but those are rarely the formal words one would use regularly in Word.
> 99.9% of people using Microsoft Office are using it on one computer.
That's not even close to true.
A lot of people use a company PC to work at the office, and a Mac laptop at home. Or vice-versa. And they make edits on their iPhone. Or Android. Or iPad. Or Surface. Some of these use an installed version, and some of them use a web version.
People today absolutely do not stick to one device, or even one operating system.
To be honest, the idea of a system dictionary that is tied to a single device doesn't make much sense in today's world. The Mac dictionary doesn't even get synced to other devices logged in with the same Apple ID!
And the Microsoft Word spellcheck feature predates the macOS one by many years.
If the custom words in your spell checker are so essential OS level is still preferable than app level because you only need to add the words to the operating systems you use not every single app you use ever.
These justifications just don't hold up to me and feels like we're starting to make excuses for why electron devs feel the need to waste time and money writing customer spell checking solutions.
Viewing one’s “computer” as a unified whole is a strange illusion we keep chasing after. Apple tries, but it just doesn’t work like that.
The “world” is no different. We have different but often overlapping protocols for all kinds of fundamental verbs in society (payment, government services, communication).
Only a handful of critical technology has seen some standardization. Stuff like electricity, language (to some extend), cars. Everything else is a complete shit-show. I don’t get why “computers” get such a hard time. These things are getting more complex than small societies.
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.
Reminds me of a story where a persons first or last name is “Null” and the system couldn’t handle it. Apparently a very common name in Lebanon or some other non-Western country
This seems like an odd thing for developers to have to do.
Why isn't it done by default by the browser? What is the browser default? (Strangely, MDN docs don't seem to indicate.) And if it's not already this, why not?
I imagine backwards compat is a big part, but also:
Dir=auto means ignore what came previously when trying to guess what direction this text is. Not setting a dir attribute means the browser should use the text in the parent/previous sibling element for figuring out what direction this element's text is. Auto might make sense as a default for a <textarea> where user input is disconnected from the html, but would be a horrible default for most tags like <b>
That suggests making the top level (document as a whole?) have an implicit dir="auto". Alternately, the default dir="auto" is overridden by any parent with an explicit dir="..." setting.
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.
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.