[Webkit-unassigned] [Bug 19785] <select> can't display right-to-left (rtl) languages

[bugzilla-daemon at webkit.org]

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


Xiaomei Ji <xji at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aharon at google.com




--- Comment #9 from Xiaomei Ji <xji at chromium.org>  2009-09-23 14:31:41 PDT ---
Hi Mitz,

I have some thought on the problem and would like to know what do you think.

For <select><optioin>:

IE in windows ignore directionality in <option> and it sets the item's writing
direction and alignment (both the selected item in menu and the items in
drop-down) based on the directionality of the <select>.

FF in windows and Mac render item in menu (for both alignment and text writing
direction) based on the directionality of the <select>, but it render the items
in drop-down (for both alignment and text writing direction) based on the
directionality of <option>. So, there is inconsistency for both alignment and
writing directionality between the items in selected menu and in drop-down
list. (See attachment).

Looks like currently, webkit uses natrual-writing-direction to display both the
selected item in menu and the items in drop-down list.

But the text-alignment of selected item in menu is always set as LEFT.

I asked Aharon's opinion on the alignemnt and writing direction of <select>.
He thinks "the directionality be estimated for each option
separately, with each option displayed in its own directionality both in the
drop-down and when chosen. The select's directionality should only affect the
position of the arrow button (and possibly the alignment of the items, in both
the dropdown and the select, which is the real issue at hand). This way, there
is no inconsistency between what the user sees in the dropdown and the chosen
item." (please refer to comment #5 in
https://bugs.webkit.org/show_bug.cgi?id=29612 for detail).

In another word, he thinks the writing direction in webkit is desired, but not
the alignment.

The text-alignment of selected item in menu is always set as LEFT in
RenderMenuList::adjustInnerStyle().

    if (PopupMenu::itemWritingDirectionIsNatural()) {
        // Items in the popup will not respect the CSS text-align and direction
properties,
        // so we must adjust our own style to match.
        m_innerBlock->style()->setTextAlign(LEFT);
        ...
    }

>From your comment #3, should we remove the above text-alignment resetting? So
that the selected item in menu is aligned based on select element's alignment,
while its directionality is still based on natural writing direction.
Or we can introduce
PopupMenu::itemNatrualWritingDirectionDomElementAlignment().

As to the items in drop-down list, looks like it is taken care by each client.
In order for each client to handle alignment and writing direction separately
for items in drop-down, I think we need to add textAlignment to PopupMenuStyle.

For example, given the following structure:
<select dir="rtl">
<option>abc CBA</option>   (where 'CBA' represents Hebrew word)
<option>CBA abc</option>
</select>

The writing direction of "abc CBA" is LTR, while writing direction of "CBA abc"
is RTL.
But both "abc" and "CBA" should be right-aligned in drop-down box (and in
selected menu). Without passing the text alignment to PopupMenuStyle, there is
no way for each client to display them as right-aligned.

In summary, we need to 
1. remove the alignment resetting in RenderMenuList::adjustInnerStyle() for
rendering selected item in the menu.
2. add textAlignment to PopupMenuStyle, so that each client could control how
to render (in writing direction and in alignment) items in drop-down.


Looking forward for your input!

Thanks,
Xiaomei

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