This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10816 - i18n comment 11 : default ignorable code points
Summary: i18n comment 11 : default ignorable code points
Status: CLOSED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-29 12:54 UTC by i18n bidi group
Modified: 2011-01-22 20:28 UTC (History)
8 users (show)

See Also:


Attachments

Description i18n bidi group 2010-09-29 12:54:19 UTC
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.
Comment 1 Ian 'Hixie' Hickson 2010-09-30 20:01:59 UTC
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?
Comment 2 Ehsan Akhgari [:ehsan] 2010-09-30 21:15:12 UTC
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.
Comment 3 Aharon Lanin 2010-10-06 18:15:41 UTC
(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).
Comment 4 Ian 'Hixie' Hickson 2010-10-12 08:56:08 UTC
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.