unicode-bidi:plaintext should make all-neutral paragraphs LTR
Reported by igo...@sisa.samsung.com, Aug 22 2013
Migrated from WebKit Bugzilla: https://bugs.webkit.org/show_bug.cgi?id=78594 Originally reported 2012-02-14 02:50 PST by Aharon (Vladimir) Lanin (firstname.lastname@example.org). Description: Created an attachment (id=126948) [https://bugs.webkit.org/attachment.cgi?id=126948] [details] [https://bugs.webkit.org/attachment.cgi?id=126948&action=edit] test case being submitted to W3C's HTML5 test suite Currently, in a unicode-bidi:-webkit-plaintext element, paragraphs that contain no strongly left-to-right (bidi class L) or right-to-left (bidi class R and AL) characters default to the element's computed direction style. This is bad because it does not conform to http://www.w3.org/TR/css3-writing-modes/, which states that "the base directionality of each bidi paragraph for which the element forms the containing block is determined not by the element's computed ‘direction’ as usual, but by following the heuristic in rules P2 and P3 of the Unicode bidirectional algorithm". In turn, http://unicode.org/reports/tr9/#P3 states that "if a character is found in P2 and it is of type AL or R, then set the paragraph embedding level to one; otherwise, set it to zero." Paragraph level 0 is LTR. Gecko's implementation of unicode-bidi:plaintext suffers from the exact same problem, but they are about to fix it. See https://bugzilla.mozilla.org/show_bug.cgi?id=726420. Please note that the exact definition of unicode-bidi:plaintext is relevant even when the element has dir=auto (which assigns unicode-bidi:plaintext by default for <pre> and <textarea>, and is probably more likely to be used than unicode-bidi:plaintext directly), even though part of the definition of dir=auto is that the element is assigned a CSS direction using the first-strong algorithm. The exact definition of still makes a difference in a case like this: <pre dir=auto> א! --> </pre> This will result in the second line being displayed <-- if unicode-bidi:plaintext for all-neutral paragraphs depends on the computed direction of the element, but it being displayed --> if all-neutral paragraphs are always LTR. The test case I am attaching is elaboration of this example. Despite all of the above, I think that there is room for "fudging" a little and making the direction of a completely empty (not just all-neutral) paragraph match the direction of the preceding paragraph, and if there is none, then the computed direction. The purpose of this would be just to set the alignment (when text-align is start or end) such that when typing a sequence of RTL paragraphs in a unicode-bidi:plaintext textarea, one will not initially start off with the caret on the left for each new paragraph. This little tweak will have no affect whatsoever on the display of text outside of a textarea, where the direction of an empty paragraph is a moot point. But this is just icing; the basic point of this bug is that all-neutral paragraphs should default to LTR. Blocks: [http://wkb.ug/50910] NEW - Master bug for HTML5 Bidi Attachments: 2012-02-14 02:50 PST: test case being submitted to W3C's HTML5 test suite [https://bugs.webkit.org/attachment.cgi?id=126948&action=prettypatch] Comments: ================================ Comment #1 Posted on 2012-02-23 00:54:11 PST by Aharon (Vladimir) Lanin (email@example.com) Please note that the corresponding bug has now been fixed in Mozilla, see https://bugzilla.mozilla.org/show_bug.cgi?id=726420
Aug 22 2013,
Aug 23 2013,
Aug 24 2013,
The following revision refers to this bug: http://src.chromium.org/viewvc/blink?view=rev&rev=156664 ------------------------------------------------------------------------ r156664 | firstname.lastname@example.org | 2013-08-24T00:49:23.140635Z Changed paths: A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/text/international/dir-auto-in-textarea-neutral-expected.html?r1=156664&r2=156663&pathrev=156664 A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/text/international/dir-auto-in-textarea-neutral.html?r1=156664&r2=156663&pathrev=156664 M http://src.chromium.org/viewvc/blink/trunk/Source/core/rendering/RenderBlockLineLayout.cpp?r1=156664&r2=156663&pathrev=156664 M http://src.chromium.org/viewvc/blink/trunk/Source/core/css/html.css?r1=156664&r2=156663&pathrev=156664 M http://src.chromium.org/viewvc/blink/trunk/Source/core/html/HTMLElement.cpp?r1=156664&r2=156663&pathrev=156664 If an element has unicode-bidi: plaintext and no strong directional characters. By default it should be LTR. BUG= 277687 Review URL: https://chromiumcodereview.appspot.com/23112019 ------------------------------------------------------------------------
Oct 9 2013,
Is this fixed?
Oct 9 2013,
Yes. Closing the bug.
Oct 10 2013,
Way to go! No longer reproduces for me in 32.0.1665.2 canary Aura on Win7.
Jan 9 2015,
Migrate from Cr-Blink-Rendering to Cr-Blink-Layout
Sign in to add a comment