[HN Gopher] Add dir="auto" to your inputs and textareas
___________________________________________________________________
Add dir="auto" to your inputs and textareas
Author : ducaale
Score : 298 points
Date : 2023-08-23 10:26 UTC (12 hours ago)
(HTM) web link (mough.xyz)
(TXT) w3m dump (mough.xyz)
| groby_b wrote:
| Uh.
|
| 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.
| scrozier wrote:
| Instead of gatekeeping "the space" with insider abbreviations
| and belittling the author, you could appreciate that they
| raised awareness of the issue.
| zlg_codes wrote:
| 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...
| scrozier wrote:
| 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. :-)
| groby_b wrote:
| I am not "gatekeeping", I'm telling you that in spaces you
| don't know there's hidden complexity, and you shouldn't rely
| on the Internet.
|
| No amount of "awareness" is taking that away.
|
| Also, please tell me where I "belittled" the author.
| jholman wrote:
| 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."
| beebeepka wrote:
| It's a shame your post got downvoted. Sometimes I don't get
| the HN mob. I have no idea what groby_b is talking about
| dpkirchner wrote:
| Uh.
|
| It was probably the uh. I don't fault you for thinking it
| might be something else.
| groby_b wrote:
| I honestly had no idea what it was, so thanks for the
| explanation. Wish I'd gotten your reply sooner, because
| I'd just have taken it it out.
| scrozier wrote:
| 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.
| Pxtl wrote:
| 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.
| [deleted]
| javajosh wrote:
| 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.
| divbzero wrote:
| _dir_ is a global attribute that can be set on any HTML element:
|
| 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.
| [deleted]
| jonny_eh wrote:
| Probably to not break existing sites.
| donatj wrote:
| 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.
| marcosdumay wrote:
| 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.
| bsmth wrote:
| I'd also add a link here to `dirname` which is an interesting one
| for including text directionality of text input in form
| submissions: https://developer.mozilla.org/en-
| US/docs/Web/HTML/Attributes...
| tracker1 wrote:
| Seems to me, that should be the default behavior.
| [deleted]
| ketanmaheshwari wrote:
| Slightly related: I recently learned that vim has `:set rl` to
| make a text go from right to left. (`:set norl` to come back to
| regular)
| slim wrote:
| thanks Bram Molenaar
| kzrdude wrote:
| and old vim has vim -A to start in arabic mode too (I have no
| idea how to use it, seems to use some input method.)
| freedomben wrote:
| Whoa that's pretty badass, and kind of fun trying to type that
| way even in English. I spent more time doing it than I should
| have
| justsomehnguy wrote:
| What about `:set td`?
| andrewmcwatters wrote:
| 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.
| willcipriano wrote:
| This is the correct solution. Updating every html form vs the
| source of a few browsers, no brainer.
|
| In the meantime, browser plug-in?
| ssdspoimdsjvv wrote:
| It always bugs me in CSS and HTML that "auto" does not equal
| "default"
| bastawhiz wrote:
| Even worse: it _sometimes_ is the default.
| [deleted]
| distantsounds wrote:
| or don't, because using fancy quotes in your HTML will have it
| not render properly.
|
| mods, pls fix the title.
| bawolff wrote:
| ? What does this have to do with anything
| eyelidlessness wrote:
| 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.
| wnoise wrote:
| Why isn't this the default?
| [deleted]
| bawolff wrote:
| 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>
| wnoise wrote:
| 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.
| pharrington wrote:
| MDN always comes to the rescue: https://developer.mozilla.org/en-
| US/docs/Web/HTML/Global_att...
| bad_alloc wrote:
| To the people wondering why this is still an issue: Most tech is
| very US- or west-centered. My name contains an Umlaut (u), which
| causes me trouble much more often than should be the case. A
| colleague of mine even changed their name by substituting a foe
| ae, to avoid this issue. We still have the benefit of mostly
| ASCII names mind you. It can get a lot worse.
| entropie wrote:
| Hello, Jurgen.
| [deleted]
| xyst wrote:
| 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
| amluto wrote:
| 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 ".<"
| drex04 wrote:
| 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.
| amluto wrote:
| 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?
| dotancohen wrote:
| You are correct. I explain this in depth here:
|
| https://dotancohen.com/howto/rtl_right_to_left.html
| rendall wrote:
| > _The first results page of Google never lies..._
|
| 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...
| JadeNB wrote:
| > 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.
| zellyn wrote:
| > I think you are responding to this sentence read literally
|
| 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.
| drex04 wrote:
| 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.
| Vanit wrote:
| [flagged]
| nickpeterson wrote:
| Just support English and eventually it won't be a problem.
| Also put all your dates in UTC. Any other low hanging fruit
| we can knock out?
| masa331 wrote:
| always export files in UTF-8
| mpixel wrote:
| only lowercase alphabetic ascii for any path or file
| name, excluding space.
|
| i will die on this hill.
| lpapez wrote:
| We will stand together, brother.
| mananaysiempre wrote:
| 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).
| phonon wrote:
| https://bugs.chromium.org/p/chromium/issues/detail?id=147072...
| crazygringo wrote:
| 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?
| [deleted]
| miduil wrote:
| 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.
| beebeepka wrote:
| 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
| sitzkrieg wrote:
| thats kinda comedic, def adding to the list of naive RTL
| handling approaches
| jorams wrote:
| 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.
| wouldbecouldbe wrote:
| yeah it's supposed to be like that. They prefer to go back the
| other way.
| whywhywhywhy wrote:
| This should be the operating systems problem to solve not
| developers of every website ever. Same with spellchecking,
| emojis, copy/paste etc.
| reaperducer wrote:
| _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.
| crazygringo wrote:
| 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.
| reaperducer wrote:
| _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.
| SanderNL wrote:
| 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.
| [deleted]
| londons_explore wrote:
| Why in 2023 is this still an issue?
|
| 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.
| sunnybeetroot wrote:
| Agreed. SwiftUI in iOS handles this out of the box.
| rpastuszak wrote:
| I was under the same impression until a user of enso (a
| psychologist, not a dev) sent me a feature request with a code
| snippet.
|
| I suspect he had some experience in reporting this category of
| bugs.
| bawolff wrote:
| 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.
| rapind wrote:
| > Why in 2023 is this still an issue?
|
| 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).
| robertoandred wrote:
| Date pickers will still be popular JS products because the
| browser native options won't match designers' requests.
| aitchnyu wrote:
| Could you confirm datetime is supported by all browsers with
| no usability quirks?
| reaperducer wrote:
| Yeah, it took a strangely long time for Safari to get a date
| picker.
|
| Now if Chrome could come onboard with hanging-punctuation{},
| I'd be set!
| cpfohl wrote:
| 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.
| someguy7250 wrote:
| 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".
| londons_explore wrote:
| 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"
| marcosdumay wrote:
| 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.
| zlg_codes wrote:
| 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.
| [deleted]
| wouldbecouldbe wrote:
| Because just rtl doesn't solve it and makes things a mess.
|
| 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.
| jesprenj wrote:
| PSA: Assume dir="auto" if none provided in browsers you develop.
| bawolff wrote:
| 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).
| ssddanbrown wrote:
| 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.
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/CSS/CSS_logical...
| jwells89 wrote:
| 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.
___________________________________________________________________
(page generated 2023-08-23 23:00 UTC)