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 ***

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.

(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.

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=""?

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.

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

(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.'

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.

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

Great example, but I think you accidentally put it in the wrong part of the spec.

Where did you expect it to be?

(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.

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.

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