This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Comment from the i18n review of: http://dev.w3.org/html5/spec/ Comment 8 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: Line breaks in the plain text displayed by the page's scripts using functions such as Javascript's alert() and confirm() should constitute UBA paragraph breaks.
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. See also the similar bug 10811
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: The strings passed to functions such as alert() are entirely Unicode strings without markup. As such, the semantics of such strings are entirely defined by Unicode. It would be inappropriate for HTML to add additional requirements that might contradict what Unicode says (now or in the future).
(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.
> If HTML does specify anything about how the text in a dialog is rendered, it > would probably be best to defer to CSS. Deferring this to CSS is a red herring; this has nothing to do with CSS. > The strings passed to functions such as alert() are entirely Unicode > strings without markup. As such, the semantics of such strings are entirely > defined by Unicode. It would be inappropriate for HTML to add additional > requirements that might contradict what Unicode says (now or in the future). Perhaps making this more explicit would help. I'm not seeing where the argument to alert() is defined as a Unicode string so I can't offer any specific text, but mentioning in the Simple Dialogs section that the given message must be displayed according to the normative requirements of Unicode, and citing as examples the mandatory line breaking rules and bidi behavior, would help here. This would make it easier for the i18n Working Group to justify the submission of tests for correct behavior. It would also clarify that white space is not supposed to be collapsed as it is when displaying HTML.
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. Re comment 4: The argument is defined as a string in the IDL. White space in HTML isn't collapsed (the effect you're referencing is merely a side-effect of the suggested default CSS rules).
I disagree with this resolution. Whether you think Unicode's requirements are adequately required by other parts of the spec or not, the point here is that it's not clear how those requirements apply to this situation, since many of them are effectively ignored for other parts of the document through processing in the presentation layer. To address this issue, I would like the spec to be explicitly clear that, to quote myself: "the given message must be displayed according to the normative requirements of Unicode" and I would like the mandatory line breaking rules and bidi behavior to be cited as examples. Wordsmith as you like, but the gist of that should be there, otherwise I consider this issue unresolved. As for white-space collapsing, it's implemented via CSS in CSS-based implementations, but it is not a side effect. The same collapsing rules need to apply to non-CSS implementations. Except in <pre> and <textarea>, the semantics of text processing in all prior versions of HTML has been that extra white space in the source code is insignificant. Like correct handling of bidi attributes, this is not a default UA stylesheet issue, but an area where HTML needs to require certain behavior regardless of presentation technology in use. As for defining the arugment as a string in the IDL, I couldn't find the IDL. Is it somewhere other than 6.3.1?
> To address this issue, I would like the spec to be explicitly clear that, to > quote myself: "the given message must be displayed according to the normative > requirements of Unicode" Unicode already requires this. What sense is there in HTML saying that? It would be like saying "User agents must implement TCP according to the TCP specification". It's true, but not because we say so because the other spec says so.
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: no new information since comment 5
Please reread comment 6. The issue is not that there aren't specs exist that require the requisite behavior. The issue is that it's not clear how various specs interact here. It may be clear to you because you have a particular viewpoint on the layering of said specs, but this is implicit in your understanding of how they fit together, and not clear to everyone else. Otherwise this issue would not have been filed. Please clarify the spec with regards to this issue, and make sure to include the examples cited in comment 6. (Also you did not answer my question about where the IDL is.)
> The issue is that it's not clear how various specs interact here. Could you please quote any text at all anywhere that contradicts Unicode here? I don't understand how there is any way to misinterpret this. There aren't any interactions at all as far as I can tell. There's just a string, and nothing but Unicode assigns any semantics to that string. > (Also you did not answer my question about where the IDL is.) It's on the Window object's interface; search for "interface Window {".
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: Did Not Understand Request Change Description: no spec change Rationale: see comment 10
For the record, this was actually fixed: http://dev.w3.org/html5/spec/Overview.html#text-rendered-in-native-user-interfaces cites "the paragraph-breaking behaviour of U+000A LINE FEED (LF) characters" in script dialog text.