New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 277687 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Email to this user bounced
Closed: Oct 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

unicode-bidi:plaintext should make all-neutral paragraphs LTR

Reported by igo...@sisa.samsung.com, Aug 22 2013

Issue description

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 (aharon@google.com).


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 (aharon@google.com)

Please note that the corresponding bug has now been fixed in Mozilla, see https://bugzilla.mozilla.org/show_bug.cgi?id=726420
 

Comment 1 by tkent@chromium.org, Aug 22 2013

Labels: Cr-Blink-Rendering Cr-Blink-RTL
Cc: igo...@sisa.samsung.com
Cc: le...@chromium.org
Owner: igo...@sisa.samsung.com
Is this fixed?
Status: Fixed
Yes. Closing the bug.
Way to go! No longer reproduces for me in 32.0.1665.2 canary Aura on Win7.

Comment 7 by laforge@google.com, Jan 9 2015

Labels: -Cr-Blink-Rendering Cr-Blink-Layout
Migrate from Cr-Blink-Rendering to Cr-Blink-Layout

Sign in to add a comment