search

whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
7.86k stars 2.58k forks source link

input field placeholders should respect the dir attribute when set to "auto" #4903

Open MarkFalconbridge opened 4 years ago

MarkFalconbridge commented 4 years ago

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.

rniwa commented 4 years ago

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.

MarkFalconbridge commented 4 years ago

Yes, exactly that.

domenic commented 4 years ago

I believe the spec already covers this in https://html.spec.whatwg.org/multipage/dom.html#directionality-of-the-attribute , in particular

The directionality of an attribute of an HTML element, which is used when the text of that attribute is to be included in the rendering in some manner, is determined...

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.

emilio commented 4 years ago

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="لوحة">
domenic commented 4 years ago

unless the spec section I mentioned is modified it should render red, but with the text right-aligned... right?

I agree with this analysis.

I think it should render green with text right-aligned

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 value="" attribute.) In that case the border should definitely be red, right?

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.

emilio commented 4 years ago

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 value="" attribute.) In that case the border should definitely be red, right?

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.

domenic commented 4 years ago

I don't think it's quite the same, personally. I think we have three sources of directionality we're considering:

  1. what the user types
  2. what the element has been configured as/inherited from the document
  3. what the placeholder says

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 :).

emilio commented 4 years ago

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 think (3) is a more consistent / less confusing of a signal than (2), in absence of value, fwiw...

From the user's perspective a placeholder seems pretty similar to the value of the input, modulo styling.

r12a commented 4 years ago

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.

r12a commented 4 years ago

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.

mustafa0x commented 4 years ago

Another reason why dir="auto rtl" (or just inheritance of dir) is needed:

dir auto rtl

I.e., weak characters align left. (The text in the picture is: "Answer the question\n1- __")

Demo: https://codepen.io/mustafa0x/pen/mdeerOp

So dir=auto's direction should default to the document's in cases where it lacks a cue.

reececomo commented 1 year ago

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.

fantasai commented 1 year ago

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:

If the element is an input element whose type attribute is in the Text, Search, Telephone, URL, or Email state, and the dir attribute is in the auto state If the element is a textarea element and the dir attribute is in the auto state

If the element's value (or its placeholder text, if placeholder text is being presented to the user in place of a value) contains a character of bidirectional character type AL or R, and there is no character of bidirectional character type L anywhere before it in the element's value, then the directionality of the element is 'rtl'. [BIDI]

Otherwise, if the element's value (or its placeholder text, if placeholder text is being presented to the user in place of a value) is not the empty string, or if the element is a document element, the directionality of the element is 'ltr'.

Otherwise, the directionality of the element is the same as the element's parent element's directionality.

ARZarkesh commented 1 year ago

In my case, using RLM (Right-to-Left Mark) Unicode worked.

aphillips commented 7 months ago

I18N WG reviewed this issue today and wants to track this as "needs-resolution"

annevk commented 4 months ago

@dbaron what do you think? Seems worth trying to tackle now that we've done most of the other directionality-related changes.