Bug 19785 – <select> can't display right-to-left (rtl) languages

• Component: CSS
• Status: RESOLVED FIXED

[Joshua J Estelle]

It seems impossible to get Safari to render a <select> with the text right justified.

This makes webpages that are localized for RTL languages (like Arabic) not look correct, as their <select> boxes can't correctly show text RTL.

Perhaps there is some tricky CSS to make this happen, but from everything I've been able to look at it does seem like anything makes Safari do the right thing.

[Dave Hyatt]

Isn't this how dropdown controls on Mac behave with RTL text?

[Dave Hyatt]

(I didn't think popup menus did right justified text for RTL on OS X.)  Since OS X doesn't flip scrollbars either in its controls, I don't think text is right justified for list boxes either, but I could be wrong.  I'll let Mitz comment.

Right-to-left pop-ups are not available in Mac OS X. It is possible to right-align menu items but indentation and markers would still be on the left. For list boxes, I think it would be okay to support text-align:right if other browsers do it, and leave the scroll bar on the right.

[Eric Seidel (no email)]

Does this make this a windows-only bug then?

[Joshua J Estelle]

This is *not* a windows only bug.  The bug impacts Safari in OS X as well.

From the sounds of it, it may be infeasible to fix in OS X?

Also, I should point out that Firefox right-aligns the text, even while leaving the scroll bar on the right.

[Jeremy Moskovich]

Related Chrome bug: http://code.google.com/p/chromium/issues/detail?id=6113

[Eric Seidel (no email)]

Correct, FF3 shows these pop-ups with the text left-justified, even on the Mac.  It seems since we paint the text ourselves, this should be "easy" to fix, if we can get a comprehensive test case which makes clear what edge cases we need to support.  Mitz is the only WebKit committer able to read an RTL language (that I know of), so a test case from an RTL speaker which demonstrates what should be done when the text is too long to fit in the popup, what should be done for multi-selects, etc. could be very useful. :)

[Yair Yogev]

the related chrome bug is now
http://code.google.com/p/chromium/issues/detail?id=6244

[Xiaomei Ji]

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

[Xiaomei Ji]

Created attachment 40019 [details]
test case

[Xiaomei Ji]

Created attachment 40020 [details]
FF's handling on the above test case

Created attachment 80470 [details]
On Mac OS X, align pop-up menu items according to the <select>’s writing direction and use <option>’s writing direction for each

[Eric Seidel (no email)]

Comment on attachment 80470 [details]
On Mac OS X, align pop-up menu items according to the <select>’s writing direction and use <option>’s writing direction for each

View in context: https://bugs.webkit.org/attachment.cgi?id=80470&action=review

> Source/WebCore/rendering/RenderMenuList.cpp:213
> +            m_buttonText->setText(s.impl(), true);

What's the true?

> Source/WebKit/chromium/src/ChromeClientImpl.h:176
>      virtual bool selectItemWritingDirectionIsNatural();
> +    virtual bool selectItemAlignmentFollowsMenuWritingDirection();

I'm surprised this interface doesn't just return a writing direction.  But maybe I'm misunderstanding.

(In reply to comment #13)
> (From update of attachment 80470 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=80470&action=review
> 
> > Source/WebCore/rendering/RenderMenuList.cpp:213
> > +            m_buttonText->setText(s.impl(), true);
> 
> What's the true?

Force, but this was not meant to be part of this change.

Created attachment 80480 [details]
On Mac OS X, align pop-up menu items according to the <select>’s writing direction and use <option>’s writing direction for each

Created attachment 80487 [details]
On Mac OS X, align pop-up menu items according to the <select>’s writing direction and use <option>’s writing direction for each

Fixed in r76983 <http://trac.webkit.org/changeset/76983>.

[Xiaomei Ji]

Comment on attachment 80487 [details]
On Mac OS X, align pop-up menu items according to the <select>’s writing direction and use <option>’s writing direction for each

View in context: https://bugs.webkit.org/attachment.cgi?id=80487&action=review

> Source/WebCore/rendering/RenderMenuList.cpp:101
> +        innerStyle->setTextAlign(style()->isLeftToRightDirection() ? LEFT : RIGHT);

what if the menu's writing direction is LTR, but it is alignment is right?

(In reply to comment #18)
> (From update of attachment 80487 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=80487&action=review
> 
> > Source/WebCore/rendering/RenderMenuList.cpp:101
> > +        innerStyle->setTextAlign(style()->isLeftToRightDirection() ? LEFT : RIGHT);
> 
> what if the menu's writing direction is LTR, but it is alignment is right?

The button and the menu items will disregard the text-align value. We are not going to center or justify menu items on Mac OS X.