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 10820 - i18n comment 16 : option element should support text-align CSS property and be displayed accordingly both in the dropdown and after being chosen
Summary: i18n comment 16 : option element should support text-align CSS property and b...
Status: RESOLVED 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:57 UTC by i18n bidi group
Modified: 2010-10-18 18:43 UTC (History)
7 users (show)

See Also:


Attachments

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

Comment 16
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 alignment via CSS or the align attribute will affect its display accordingly in both the dropdown and after being chosen.
Comment 1 Ian 'Hixie' Hickson 2010-10-07 19:44:43 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 2 contributor 2010-10-07 19:45:23 UTC
Checked in as WHATWG revision r5589.
Check-in comment: Add a note about keeping the alignment right for <select>
http://html5.org/tools/web-apps-tracker?from=5588&to=5589
Comment 3 Ian 'Hixie' Hickson 2010-10-07 19:47:46 UTC
*** Bug 10819 has been marked as a duplicate of this bug. ***
Comment 4 Aharon Lanin 2010-10-13 22:20:22 UTC
(In reply to comment #2)
> Checked in as WHATWG revision r5589.
> Check-in comment: Add a note about keeping the alignment right for <select>
> http://html5.org/tools/web-apps-tracker?from=5588&to=5589

The revision is problematic. It adds:

<p>User agents are expected to consistently render the labels in a <code>select</code>, in particular ensuring that any left-to-right or right-to-left alignment is consistent whether the label is being displayed as part of the page or in a menu control.</p>

There are several problems:

1. Alignment values include "left" and "right", but not "left-to-right" or "right-to-left". Those ("ltr" and "rtl") are direction values.

2. The meaning is unclear. "User agents are expected to consistently render the labels in a <code>select</code>" can be easily misunderstood to mean that some aspect(s) of rendering, e.g. direction, should be consistent across all the labels in a select, i.e. all the labels should be aligned according to the select's alignment value. That was *not* the bug's intent. The consistency that this bug and bug 10819 demand is in the way a label is displayed before and after being selected. That is, if a label was displayed in the ltr direction (e.g. "hello!", not "!hello") before being selected (in the drop-down), it should still be ltr after being selected - even though the <select> may be rtl (that's bug 10819). This is currently not always the case in Firefox or Chrome. And if a label was displayed left-aligned before being selected, it should still be displayed left-aligned after being selected (that's this bug). This is currently not always the case in Firefox. It is possible that the revision was in fact trying for the consistency we hand in mind when it said "whether the label is being displayed as part of the page or in a menu control", but I am not sure what "part of the page" and "menu control" mean here.

Now, the bug was also demanding one more thing: that the option element should support the text-align CSS property. I now see that this demand is inappropriate for two reasons:

- It is a CSS issue, not HTML.
- It would result in options with different direction in having different alignment by default. This is neither what most users want nor what browsers (with the single exception of Firefox) do.

I therefore want to drop that demand. The HTML spec revision that I would therefore want is:

<p>User agents are expected to render a label in a <code>select</code> with the same direction and alignment it had before being chosen after it has been chosen.</p>
Comment 5 Ian 'Hixie' Hickson 2010-10-14 10:07:25 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:

"part of the page" means in the browser rendering area, like any other content on the page.
"in a menu control" means in a drop-down or pop-up widget or any other similar construct.

This seems clear to me.

I've tried to clarify the rest of the text.

I'll leave the direction stuff for bug 10819.
Comment 6 contributor 2010-10-14 10:07:55 UTC
Checked in as WHATWG revision r5632.
Check-in comment: word-smithing
http://html5.org/tools/web-apps-tracker?from=5631&to=5632