10816 2010-09-29 12:54:19 +0000 i18n comment 11 : default ignorable code points 2011-01-22 20:28:15 +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 public-html-admin public-html-wg-issue-tracking public-i18n-bidi public-html-bugzilla oldest_to_newest 39946 0 public-i18n-bidi 2010-09-29 12:54:19 +0000 Comment from the i18n review of: http://dev.w3.org/html5/spec/ Comment 11 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:The HTML specification should require user agents to implement the Unicode spec re Default Ignorable Code Points (Unicode Standard version 5.2, Chapter 5 (http://unicode.org/versions/Unicode5.2.0/ch05.pdf), section 5.21), including never displaying the directional formatting characters (LRM, RLM, LRE, RLE, LRO, RLO, and PDF) inappropriately (e.g. as empty boxes or advance widths) even if the underlying platform does not handle them properly. In particular, this must be the case for script dialog text, page titles, and tooltips. Currently, directional formatting characters are most often displayed inappropriately in these context, since user agents mostly rely on the operating system to display the text in these contexts correctly, which does not happen because most LTR users' machines do not have RTL characters support installed. As a result, web applications are unable to use directional formatting characters around LTR text to make sure it is displayed correctly in an RTL context, since doing so will make it display incorrectly in the far more common LTR context. 40285 1 ian 2010-09-30 20:01:59 +0000 Since Unicode already requires that these characters be handled in a particular way, why would having HTML reiterate this make any difference? Surely the implementations are already non-conforming? 40305 2 ehsan 2010-09-30 21:15:12 +0000 For things like script dialog text or window title, the browser might hand off the rendering to the OS, and it's the OS which sometimes fails to handle these characters properly, in this case the browser should prevent those characters from being passed to the OS for rendering in the first place. 40730 3 aharon.lists.lanin 2010-10-06 18:15:41 +0000 (In reply to comment #2) > For things like script dialog text or window title, the browser might hand off > the rendering to the OS, and it's the OS which sometimes fails to handle these > characters properly, in this case the browser should prevent those characters > from being passed to the OS for rendering in the first place. Right. That's why the bug says "never displaying the directional formatting characters [...] inappropriately [...] *even if the underlying platform does not handle them properly*" (emphasis added). 41015 4 ian 2010-10-12 08:56:08 +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: If the underlying platform handles them incorrectly, then that's a bug in the underlying platform. Either the platform should be fixed, or the user agent should work around it. In either case, however, it has nothing to do with HTML. If the Unicode spec requiring something isn't enough, then the HTML spec requiring the same thing isn't going to make any difference.