10820 2010-09-29 12:57:50 +0000 i18n comment 16 : option element should support text-align CSS property and be displayed accordingly both in the dropdown and after being chosen 2010-10-18 18:43:53 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified PC Windows XP RESOLVED FIXED P2 normal --- 1 public-i18n-bidi ian aharon.lists.lanin ayg ian mike public-html-admin public-html-wg-issue-tracking public-i18n-bidi public-html-bugzilla oldest_to_newest 39950 0 public-i18n-bidi 2010-09-29 12:57:50 +0000 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. 40795 1 ian 2010-10-07 19:44:43 +0000 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. 40796 2 contributor 2010-10-07 19:45:23 +0000 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 40799 3 ian 2010-10-07 19:47:46 +0000 *** Bug 10819 has been marked as a duplicate of this bug. *** 41269 4 aharon.lists.lanin 2010-10-13 22:20:22 +0000 (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> 41344 5 ian 2010-10-14 10:07:25 +0000 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. 41345 6 contributor 2010-10-14 10:07:55 +0000 Checked in as WHATWG revision r5632. Check-in comment: word-smithing http://html5.org/tools/web-apps-tracker?from=5631&to=5632