[Webkit-unassigned] [Bug 27889] [Chromium] RTL autocomplete popup is not layout correctly.

Thu Aug 6 02:49:20 PDT 2009

https://bugs.webkit.org/show_bug.cgi?id=27889

--- Comment #10 from Aharon (Vladimir) Lanin <aharon at google.com>  2009-08-06 02:49:16 PDT ---
(In reply to comment #8)
Please see my comments inline.

> I attached the display of "שש!" in Safari 4.0.2 in Windows.
> It is displayed as RTL (the element directionality) in input field, but it is
> displayed as LTR in the pop-up list.

My mistake, you are right. I was looking at the input itself - I did not get
the dropdown until I entered a few more values starting the same way.

> Looks IE8 supports auto-complete, but it displays "hi!" and "שש!" in the pop-up
> list as LTR using the test page.

I don't have IE8 yet. I guess it looks like all the browsers are using the
browser language directionality, which I think is just terrible.

> > In my opinion, it is Chrome's current behavior re directionality here that is
> > the most useful. In most cases, a text input needs to be capable of accepting 
> > and displaying correctly - both LTR and RTL values. 
> > Thus, our BiDi support
> > recommendations for web pages is to add directionality auto-detection scripts
> > to most inputs that after each keystroke check the directionality of the
> > current input value and adjust its dir and align values accordingly. Thus, both
> > LTR and RTL values could have been submitted in the past, and all need to be
> > displayed correctly, so checking the directionality of each value in the
> > dropdown as Chrome does is the best.
> 
> 
> 
> Do you mean even if the text input field is marked as RTL,
> it should display "hi!" in such input field as LTR?
> and/or it should displayed "hi!" as LTR in the pop-up list? 

I meant that it should be displayed as LTR in the autofill dropdown, but RTL in
the input - unless a page script changes input's dir at that point - as it does
now.

> If that is the case, what is the point of setting "dir" in the input field?

To control how the input itself is displayed, not the dropdown. That, of course
raises the logical question: if that browser does directionality auto-detection
on the dropdown values, shouldn't it do it for the input itself?

Jeremy raised this question outside of the dropdown context. My response was
and is that this would be a good thing - but only if the page requested that
the browser do so, e.g. via a new dir=auto value. There is a discussion going
on re adding dir=auto or something like that to HTML5. I do not think it would
be a good idea to do directionality auto-detection on input values without
dir=auto, since it would interfere with the scripts that we put in to do that
right now, and we would have to modify the scripts to make an exception for
Chrome. Furthermore, doing auto-detection in inputs does not do anything for
when the value is later displayed in another page. And I do not think it would
be a good idea to implement dir=auto in Chrome before its design has been
completed, since it would interfere with whatever the eventual standard will
be. 

The reason that I do like directionality auto-detection on the autofill
dropdown values is that unlike the input itself, the page has absolutely no
control over these, and can not do auto-detection for them in script.

> Or you mean "dir" should not be needed for autofill and <select>, a webpage
> should be using auto-detect script to detect/display its text directionality
> automatically?

Yes, I do think that in the current HTML standard, a webpage should be doing
its own auto-detection in script on inputs. For <select>, whoever prepares the
HTML of the <option>s - either the server or page script - should be using
LRE|RLE and PDF to declare the ones that have directionality opposite to that
of the <select>. (The dir attribute does not seem to work on <option> and you
certainly don't want script fooling with it on the <select>, since it controls
on which side the down arrow is displayed.) For autofill, however, the page
simply has no control over the way the autofill values are displayed.

> If the auto-detect only applies to display text in pop-up list, that will cause
> in-consistency of the text displayed in input (or <select> box) and text
> displayed in the the pop-up list.

Let's leave <select> out of it, it's different (see below). But for autofill,
yes, the result is inconsistent when the page does not have script to update
the input's dir. So, should we do what's best for the pages that don't have
such script (unfortunately, that's most pages), or what's best for the pages
that do? I am not sure... I don't see a way to please both. The simple answer
is to do what's best for the majority, but that leaves no way for the page to
achieve the truly correct behavior.

So for autofill my answer, unfortunately, is "I don't know". However, I do know
that the current behavior in the other browsers is bad. If you decide to take
away the auto-detection in the autofill dropdown, please use the <input>'s
directionality for them, not the browser's.

Now, on to <select>.

> 
> For example, the following <select>page:
> https://bugs.webkit.org/attachment.cgi?id=14607&action=view
> 
> If you select the 2nd item, you can see the text displayed in the option box
> (with "English" at very right) and text displayed in the pop-up list ("English"
> displayed at the very left) are laid-out different.
> 
> The text in option box is displayed as LTR (because the dir of <select> is
> LTR), and the same text in the pop-up list is displayed as RTL (because
> directionality is auto-detected using the first strong directional character's
> directionality).
>
> In such case, what should be the correct behavior?
>
> (In fact, Safari 4.0.2 display the text in RTL directionality in both option
> box and pop-up list, although I do not know how Safari does it? And why it can
> do such in <select> but not in autofill).

That really is quite interesting. I do not know what they are doing, but I like
the outcome very much. It is exactly what I want. Note that when you select the
second value in Safari, it gets displayed as RTL in the <select> too - there is
no inconsistency. And what's best, I do not think that LRE|RLE + PDF in the
<option> values, when present, would interfere with what Safari is doing.

It is quite possible that Safari chose to do this for <select>, but not for
text inputs, precisely because of the collision with the text input's dir
value, which is not an issue for <select>.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.