Created attachment 126948 [details] 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.
Please note that the corresponding bug has now been fixed in Mozilla, see https://bugzilla.mozilla.org/show_bug.cgi?id=726420
Related patch in blink: https://src.chromium.org/viewvc/blink?revision=156664&view=revision
This issue is still reproducible in Safari 15.5 on macOS 12.4. All other browsers Chrome and Firefox matches each other. Thanks!
<rdar://problem/94161105>
I am not able to reproduce this now in Safari 16 and Safari Technology Preview 154 using attached testcase and both look same. Is it something fixed since Safari 15.5? Can someone confirm besides myself? Thanks!