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 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.
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?
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.
(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).
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.