Add dir=“auto” to your inputs and textareas(mough.xyz) |
Add dir=“auto” to your inputs and textareas(mough.xyz) |
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.
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.
And, no, this is not about oppressing minorities.
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.
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).
I think you are responding to this sentence read literally:
> 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...
but I'm almost 100% confident that it was meant with the sarcasm it deserves.
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 “.<“
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.
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?
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_logical...
If I search for textarea and BiDi text, in pretty much all variations I can think of https://www.w3.org/International/talks/1602-oman is one of the top links.
And right in there, the "What if you don't know the direction in advance" section, https://www.w3.org/International/talks/1602-oman/#advance
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.
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.
In the meantime, browser plug-in?
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.
I threw pretty much all his html, CSS and JS once I was allowed to render most of the game with WebGL
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.
it is one of maybe 12 global non-event attributes.
Later then I just had no reason to read specs, HTML I wrote usually worked. And when not, there was google.
http://khumuunbichig.montsame.mn/index.php?command=newsall&r...
mods, pls fix the title.
Frameworks and browsers should be designed that if you totally ignore rtl support, the browser/framework just does some usable default.
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 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).
Now if Chrome could come onboard with hanging-punctuation{}, I'd be set!
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
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.
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.
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.
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.
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?
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>
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...
No amount of "awareness" is taking that away.
Also, please tell me where I "belittled" the author.
Full RTL flips the entire application, and most styling & libraries had a hard time with that.
For instance in react native, the react native flatlist will have some weird quirks doing that.
I suspect he had some experience in reporting this category of bugs.
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.
"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. :-)
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."
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."
It was probably the uh. I don't fault you for thinking it might be something else.
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.
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.
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.
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.
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.