10811 2010-09-29 12:36:27 +0000 i18n comment 6 : U+2028 and U+2029 in dialog text 2011-01-22 20:22:48 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified PC Windows XP CLOSED WONTFIX P2 normal --- 1 public-i18n-bidi ian aharon.lists.lanin ayg ehsan ian mike mjs public-html-admin public-html-wg-issue-tracking public-i18n-bidi public-html-bugzilla oldest_to_newest 39941 0 public-i18n-bidi 2010-09-29 12:36:27 +0000 Comment from the i18n review of: http://dev.w3.org/html5/spec/ Comment 6 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/#newline-as-separator [http://www.w3.org/International/docs/html-bidi-requirements/#newline-as-separator] . Here is the proposal made there: The LINE SEPARATOR (U+2028) and PARAGRAPH SEPARATOR (U+2029) characters in the plain text displayed by the page's scripts using functions such as Javascript's alert() and confirm() should break lines. PARAGRAPH SEPARATOR characters in these elements should constitute UBA paragraph breaks, while LINE SEPARATOR characters should constitute UBA whitespace, as defined by the Unicode standard. 39972 1 mjs 2010-09-29 16:06:22 +0000 Currently HTML doesn't specify anything about how the text shown in dialogs (such as via alert()). It would be odd to have only this one requirement. If HTML does specify anything about how the text in a dialog is rendered, it would probably be best to defer to CSS. 40688 2 ehsan 2010-10-06 02:10:07 +0000 (In reply to comment #1) > Currently HTML doesn't specify anything about how the text shown in dialogs > (such as via alert()). It would be odd to have only this one requirement. That's true, but why is it sufficient reason to exclude this from the HTML5 specification? > If HTML does specify anything about how the text in a dialog is rendered, it > would probably be best to defer to CSS. I find this argument weak, as there is currently no way for CSS to affect how context in such dialogs is rendered. 40745 3 aharon.lists.lanin 2010-10-06 21:18:06 +0000 (In reply to comment #2) > (In reply to comment #1) > > Currently HTML doesn't specify anything about how the text shown in dialogs > > (such as via alert()). It would be odd to have only this one requirement. > > That's true, but why is it sufficient reason to exclude this from the HTML5 > specification? > > > If HTML does specify anything about how the text in a dialog is rendered, it > > would probably be best to defer to CSS. > > I find this argument weak, as there is currently no way for CSS to affect how > context in such dialogs is rendered. Also, this is not at all a good match for CSS. Bidi ordering is not just a matter of presentation. Although CSS has bidi properties like direction and unicode-bidi, these are only properly used to implement HTML mark-up (dir attribute, bdo element). For documents, the recommendation is to use HTML mark-up, not them. See <http://www.w3.org/TR/i18n-html-tech-bidi/#ri20030728.092130948>. 41032 4 ian 2010-10-12 09:22:15 +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: Rejected Change Description: no spec change Rationale: As far as I can tell this requirement makes as much sense as requiring that characters in the string be rendered so that they are recognisably similar to the glyphs that Unicode shows, or that text should be rendered with glyphs next to each other rather than on top of each other. Unicode defines the semantics of these characters. If the browsers don't honour them, then that's a violation of Unicode's semantics. I don't see what that has to do with HTML. Adding a requirement to follow the requirements in Unicode doesn't make any difference to whether the requirements will be followed or not.