-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
input field placeholders should respect the dir attribute when set to "auto" #4903
Comments
You mean that when the placeholder text is RTL, it still gets displayed left aligned? That does indeed seems like an obvious oversight and should be addressed in the spec if any. |
Yes, exactly that. |
I believe the spec already covers this in https://html.spec.whatwg.org/multipage/dom.html#directionality-of-the-attribute , in particular
I'll close this since it seems pretty clear to me that the spec covers this, but if I missed something, I'm happy to re-open it. /cc @emilio as in the Gecko bug he found the spec section on the directionality of the element, but not the one on attributes. |
So is this supposed to render a red or a green border? I think it should render green with text right-aligned, but unless the spec section I mentioned is modified it should render red, but with the text right-aligned... right? That looks wrong. <!doctype html>
<style>
input {
border: 1px solid red;
}
input:dir(rtl) {
border-color: green;
}
</style>
<input dir="auto" placeholder="لوحة"> |
I agree with this analysis.
Well, consider a slight modification of your case, where the element's value has been given some LTR text. (Either via the user typing, or via a Given an initial state with no value, and dir=auto, it seems that instead of guessing based on the placeholder, we should guess based on the document's directionality. Which IIUC will be LTR, or at least, not RTL. Right? So that's why I think red is still more correct. If you want to impact the directionality of input elements with no value, you should change their directionality directly, instead of having it inferred from placeholder. I'll reopen for further discussion, but I still feel like the current spec is pretty reasonable here. |
Sure, but then the placeholder isn't used for rendering. If the user types ltr it should switch from green to red, but that's the same as if the value is rtl and the user deletes it and writes ltr. |
I don't think it's quite the same, personally. I think we have three sources of directionality we're considering:
I think we all agree (as does the spec) that (1) is most important. But if the user doesn't type anything, we have to pick a fallback position. To me, (2) is a better signal than (3), whereas I am hearing you say that (3) is a better signal than (2). I'm not sure exactly how to make a decision here between these two positions, but I'll say that mine is not strongly held, so one potentially-easy way out is if a bunch of people show up explaining why I'm wrong. Even better if they are folks from @whatwg/i18n :). |
I think (3) is a more consistent / less confusing of a signal than (2), in absence of From the user's perspective a placeholder seems pretty similar to the |
The string used for the examples above is a little too simple to reveal the full extent of the problem here. For example, all the browsers also fail to apply RTL direction to the rendering of the text, in addition to failing to display on the right side of the control. Take for example the sentence: "في XHTML 1.0 يتم تحقيق ذلك بإضافة العنصر المضمن bdo." [Example updated because GitHub seems to have introduced first-strong direction detection since it was originally created.] What you see above is how this is displayed in the browsers: it uses a LTR base direction. If you add dir=rtl to the container of this string, you get the following (correct) rendering, where the several directional runs are in the reverse order. "في XHTML 1.0 يتم تحقيق ذلك بإضافة العنصر المضمن bdo." Needless to say, trying to understand such a sentence when it has the wrong directionality is difficult, and editing it is worse. To me, this indicates that the base direction is not being set at all for the placeholder text, and i'm pretty sure it needs to be set on the form control in order to work. That would mean that if there is no text in an input control with auto direction, and there is a RTL placeholder, the input control should have its direction set to RTL. Of course, if a user then types in some Latin text, the direction of the input control should then be changed to LTR. However, note also that I don't necessarily agree, btw, that what the user types is always the better signal. If the user types: HTML و CSS: تصميم و إنشاء مواقع الويب the word HTML should appear on the right side of the field even though the first strong letter is LTR. If that isn't done, it can again become very confusing to read and edit the text, especially in a textarea element. This can be handled using a 4th source of directionality where the user selects the directionality of the form field by choosing direction from a context menu or via keypresses (see https://www.w3.org/International/questions/qa-html-dir#userexplicit). That, to my mind, needs to take precedence over what the user actually types. (I also think that if the direction of the form control is not set to auto, then that should override what the user types too - for similar reasons, but i'm writing this quickly and may need to give some more consideration to that.) Bidi is complicated. Hope that helps. |
I also meant to say that getting the alignment of the placeholder text right (ie. to the right of the input control for arabic text) and applying correct base direction behaviour should be the prime objective here. If the arabic placeholder text appears on the left of the input control it just looks broken. |
Another reason why I.e., weak characters align left. (The text in the picture is: "Answer the question\n1- ______") Demo: https://codepen.io/mustafa0x/pen/mdeerOp So |
Although the HTML spec states that the directionality of a directionality-capable attribute should be determined by the first character in the attribute's value [1], at least Chrome, Safari, and Firefox (probably others) don't seem to follow this [2] which can result in placeholder text appearing on the wrong side of the input. Because of this, setting the `dir` attribute on `input` elements should be up to the client to decide (this is possible via `v-bind="$attrs"`). Notably, Vector legacy's search input does not set a dir attribute which is how it bypasses this issue. Equivalent patch from WVUI at Ib98f2e7cdc. [1] https://html.spec.whatwg.org/multipage/dom.html#directionality-of-the-attribute [2] whatwg/html#4903 Bug: T279674 Change-Id: I7b137a0db7b3652e572f1ac5bad1ae55fbb1cb04
Any update on this? edit: for context our website is a design tool where users enter both RTL and LTR text - we have a number of locales where the default should be RTL (like placeholders and forms), but we want to allow users to also enter LTR script text. |
Fwiw, I agree with @r12a and @emilio that reading dir=auto from the placeholder instead of the value makes sense. I think the relevant edits would go here: https://html.spec.whatwg.org/multipage/dom.html#the-directionality Something like:
|
In my case, using RLM (Right-to-Left Mark) Unicode worked. |
I18N WG reviewed this issue today and wants to track this as "needs-resolution" |
@dbaron what do you think? Seems worth trying to tackle now that we've done most of the other directionality-related changes. |
Both Google Chrome and Mozilla Firefox have bugs raised against them regarding the placeholder attribute of an input field when the dir attribute of the input field is set to "auto".
Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=982674#c1
Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1573762.
In both browsers if you add Arabic text to the input field it correctly appears on the right hand side of the input but the placeholder is rendered on the left.
Firefox suggest that this is working as per the spec and that perhaps the spec should be updated to improve this experience.
The text was updated successfully, but these errors were encountered: