[Webkit-unassigned] [Bug 23124] RTL: Directionality always reset on hard line break

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=23124


Aharon (Vladimir) Lanin <aharon at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aharon at google.com




--- Comment #18 from Aharon (Vladimir) Lanin <aharon at google.com>  2009-08-30 02:03:03 PDT ---
A few thoughts about this issue.

- The most important test case for the effect of <br> on the Unicode BiDi
Alogorithm is as follows:

1. Start with &#x05d0;.
2. &#x05d1; is the next step.

The period on the first line is should come out to the right of the aleph and
the "2." on the second line should come out to the left of the bet.

That is where Firefox and Opera go wrong.

The second most important test case is that in <span
dir=rtl>&#x05d0;.<br>&#x05d0;.</span>, the two lines should comeout the same
(with the period to the left of the aleph).

This is where WebKit is currently going wrong.

The issue of the effect of <br> on embedding levels started via Unicode BiDi
formatting characters like LRE is of secondary importance, since these really
aren't supposed to be used in HTML documents except where mark-up can't be
used.

As far as I am concerned, the only legitimate reason for these characters to
appear in HTML documents otherwise is as a result of including plain text in
it. One HTML-escapes the plain text, of course, and translates newlines to
<br>s - but what is one supposed to do with the LREs etc.? What usually happens
is that the LREs are ignored, i.e. left in the HTML document as is. It is good
in such cases for the <br>s (that used to be newlines) to close them, as they
had done in the original plain-text context, where a newline is a paragraph
break.

- However <br> behaves in this whole matter, <hr> and embedded block elements
(e.g. <div></div>) should behave the same.

- The Unicode BiDi algorithm unfortunately does not deal with a good parrallel
to <br>. The obvious candidate would, of course, be paragraph breaks, except
that paragraph breaks are supposed to terminate all embedding levels, and it
makes no sense for <br> to terminate the effect of the dir attributes of its
ancestors. It is the lack of a good parallel that caused all the browsers to do
such different things.

- Given that the Unicode BiDi Algorithm gives no clearcut answer on what the
effect of <br> should be, and that IE, Firefox, and WebKit currently all do
different things, I do not think that WebKit needs to do exactly what IE or
Firefox does (unless that's what makes sense).

- IE's approach of digging into the stack and killing the embedding levels
started with LRE, RLE, LRO,and RLO, but not those started by HTML elements
within the scope of these characters and their matching PDFs gives me the
willies. I would like to offer an alternative: close embedding levels up to,
but not including the topmost one started by mark-up. That way, we don't have
to do surgery on the stack, but we still close LREs started in included plain
text. Here is a test case:

<div dir=ltr>
==>
&#x202B;
=>>
<span dir=ltr>
==>
&#x202B;
=>>
&#x202A;
==>
<br>
==>
&#x202C;
==>
&#x202C;
==>
</span>
=>>
&#x202C;
==>
</div>

The result should be that all the ==> arrows point left, while all the =>>
arrows point right.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.