This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10819 - i18n comment 15 : option element should support the dir attribute and be displayed accordingly both in the dropdown and after being chosen
Summary: i18n comment 15 : option element should support the dir attribute and be disp...
Status: CLOSED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-29 12:56 UTC by i18n bidi group
Modified: 2011-01-22 20:32 UTC (History)
7 users (show)

See Also:


Attachments

Description i18n bidi group 2010-09-29 12:56:48 UTC
Comment from the i18n review of:
http://dev.w3.org/html5/spec/

Comment 15
At http://www.w3.org/International/reviews/html5-bidi/
Editorial/substantive: S
Tracked by: AL

Location in reviewed document:
undefined [http://dev.w3.org/html5/spec/spec.html#contents]

Comment:This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see 
http://www.w3.org/International/docs/html-bidi-requirements/#option [http://www.w3.org/International/docs/html-bidi-requirements/#option]
. Here is the proposal made there:

The HTML specification should explicitly state that the <option> element's computed direction will take its dir attribute (explicit or inherited) into account, and will be used to display the option's text in both the dropdown and after being chosen.
Comment 1 Ian 'Hixie' Hickson 2010-10-07 19:47:46 UTC
This seems to be the same as bug 10820. Please reopen and clarify the issue if this is incorrect.

*** This bug has been marked as a duplicate of bug 10820 ***
Comment 2 Aharon Lanin 2010-10-13 20:50:54 UTC
This is talking about direction.  Bug 10820 is talking about alignment. The two are distinct. One can have dir=ltr on an <option> (e.g. "mamma mia!", so it does not get displayed as "!mamma mia" in an RTL page) and yet have text-align:right, since one wants it to line up with the other options in the select. Both need to be obeyed when displaying the option - both before and after it has been selected.
Comment 3 Aharon Lanin 2010-10-13 22:32:16 UTC
(In reply to comment #2)
> This is talking about direction.  Bug 10820 is talking about alignment. The two
> are distinct. One can have dir=ltr on an <option> (e.g. "mamma mia!", so it
> does not get displayed as "!mamma mia" in an RTL page) and yet have
> text-align:right, since one wants it to line up with the other options in the
> select. Both need to be obeyed when displaying the option - both before and
> after it has been selected.

Currently, no browser listens to the text-align on an <option> (or a <select>, for that matter). Although bug 10820 used to demand that this change, I have modified it to no longer do so.

On the other hand, I still very much want the direction (e.g. as set by the dir attribute) on an <option> to be obeyed, both before and after it has been selected. Currently this is only the case in Firefox.
Comment 4 Ian 'Hixie' Hickson 2010-10-14 09:31:34 UTC
Oh, my bad. So this is asking for the same clarification as in bug 10818, but for <option> text rather than for title="" and alt=""?
Comment 5 Ian 'Hixie' Hickson 2010-10-15 21:52:45 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: see diff given below
Rationale: I've added a section to cover this kind of issue in general. There doesn't seem to be a need to specifically list the dozens of ways that text can end up in native UI, so I haven't listed specifics. I'd be happy to add examples if that would help; contact me on IRC if you would like examples.
Comment 6 contributor 2010-10-15 21:53:12 UTC
Checked in as WHATWG revision r5637.
Check-in comment: clarify that directionality affects native UI
http://html5.org/tools/web-apps-tracker?from=5636&to=5637
Comment 7 Aharon Lanin 2010-11-03 16:42:44 UTC
(In reply to comment #5)
> Status: Partially Accepted
> Change Description: see diff given below
> Rationale: I've added a section to cover this kind of issue in general. There
> doesn't seem to be a need to specifically list the dozens of ways that text can
> end up in native UI, so I haven't listed specifics. I'd be happy to add
> examples if that would help; contact me on IRC if you would like examples.

Sorry, but I am unsure how to contact you on IRC.

The diff looks great! However, I think that an example clarifying the situation with option would be particularly in order, since the situation there is confused by the fact that the option's text is displayed as "the value" of the select after it has been chosen, and the select's dir can go the other way. Firefox and Chrome make that mistake. Thus, I would suggest adding something like the following immediately after the text added by the diff:

'For example, the "HTML!" in "<div dir=rtl>...<select><option dir=ltr>HTML!</option></select>...</div>" should be shown correctly in LTR (not garbled as "!HTML" in RTL) both before and after being selected.'
Comment 8 Ian 'Hixie' Hickson 2010-11-03 23:13:44 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: Concurred with reporter's comments.
Comment 9 Aharon Lanin 2010-11-03 23:43:32 UTC
contributor@whatwg.org says (2010-11-03 23:14:20 UTC):
Checked in as WHATWG revision r5668.
Check-in comment: Added example of select directionality issue
http://html5.org/tools/web-apps-tracker?from=5667&to=5668
Comment 10 Aharon Lanin 2010-11-03 23:47:08 UTC
Great example, but I think you accidentally put it in the wrong part of the spec.
Comment 11 Ian 'Hixie' Hickson 2010-11-04 07:04:35 UTC
Where did you expect it to be?
Comment 12 Aharon Lanin 2010-11-04 13:14:52 UTC
(In reply to comment #11)

I had expected it to be right after the main part of the clarification that was added in <http://html5.org/tools/web-apps-tracker?from=5636&to=5637>. You seem to have added it in a different area entirely, some 1000 lines earlier.
Comment 13 Ian 'Hixie' Hickson 2010-11-05 00:57:15 UTC
As far as I can tell, it's added to the same section. If you're looking at line numbers in the diff, you should ignored those, the file undergoes a _lot_ of churn and sections move up and down a lot as a result.
Comment 14 Aharon Lanin 2010-11-08 10:10:06 UTC
(In reply to comment #13)
> As far as I can tell, it's added to the same section. If you're looking at line
> numbers in the diff, you should ignored those, the file undergoes a _lot_ of
> churn and sections move up and down a lot as a result.

Part of what threw me off was the sentence that intervenes between the definition and the example, i.e. "Text from scripts (e.g. the argument to window.alert()) is expected to be rendered as a separate bidirectional algorithm paragraph." That is a separate rule that has nothing to do with the example, and ideally should come after the example. (That sentence also has issues of its own that I will be writing about under bug 10827, to fix which it was added.)