Objective: Improve RTL handling in webkit editing and layout/rendering.
Mailing list: email@example.com
Members: Alex Komoroske (PM), Xiaomei Ji, Ryosuke Niwa, Jeremy Moskovich, Levi Weintraub, Uri Bernstein, Aharon Lanin, Roland Steiner, Jason Elbaum, Ahmed Hassan, Mohamed Elhawary, Michal Levin (UX).
RTL in Rich Text Edit in browserscope.
For right-to-left text, logical order (the order the text is stored) and visual order (the order the text is displayed) are not the same. They are not just the reversed order of each other when bi-directional text is involved. They also don't have a simple relationship (without going through reordering resolved levels in the Unicode Bidi Algorithm). For example, the last logical run of text could be a in the middle visually (not visually first neither visually last).
In the following examples, I will use uppercase Latin letters to represent RTL (e.g. Hebrew) letters, whereas lowercase Latin letters will represent LTR (e.g. Latin) letters. This is the convention, as it makes it easier for people who can not read RTL languages to understand the examples.
Consider, for example, the text with the following logical representation: latinHEBREWmore (this example deliberately omits spaces, in order to avoid the issues associated with resolving their directionality). This text is displayed on the screen as latinWERBEHmore.
Consider the logical position between n and H. This is immediately after n, so it maps to the visual position between n and W. But it is also immediately before H, so it also maps to the visual position between H and m.
Now, consider the visual position between n and W. It is immediately after n, so it can be mapped to the logical position between n and H. But it also immediately after W, so it can also be mapped to the logical position between W and m.
Bidirectional text is stored logically, and (obviously) displayed visually. The caret, being a graphical element, corresponds to a visual location. The user can manipulate text and move the caret through a combination of logical functions (such as typing or deleting) and visual functions (such as using the arrow keys). Therefore, the problem of mapping between logical and visual positions in a way that meets the user's expectations is the central problem of bidirectional editing.[Bidi editing in Mozilla]IBM has a non-trivial algorithm for rendering the caret in correct position in bi-directional text.
As mentioned above, mapping between logical and visual positions is the
central problem of bidirectional editing. But, there is no standard on how
such mapping should be done. Different browsers behave differently. For
example, a logical string "123ABC" (where 123 represents Arabic number
and ABC represents Arabic letter) is rendered as "CBA123" visually when
the paragraph directionality is left-to-right. The visual positions in Firefox, IE, and Chrome/WebKit are as following:
Internet Explorer: (0)(1)(7)C(6)B(5)A(4)1(2)2(3)3Another case of lacking clear spec is that there is no consensus on whether a UI function should behave logically or visually. Different browsers might behave differently. For example, IE handles cursor movement (arrow keys) as logical function, while Firefox (by default) and WebKit [after a long debate on the topic] handle it as visual function. For example, there are always discussions on whether selection should be treated as visual or logical. Currently, IE, Firefox (by default) and WebKit all treat selection as a logical operation. But Firefox also provides options to toggle between visual and logical behavior. For example, whether HOME & END should put the caret at the visual extreme or they should be considered as logical operation. Currently, IE and WebKit handle HOME & END as putting the caret at the visual extreme, while Firefox (by default) handles it as logical operation.
For some HTML elements, there is no standard defined on how they should be rendered in RTL or in a bi-directional context. Different browsers behave differently. Since RTL users are mostly adjusted to the behavior of IE, they would expect the same behavior as that of IE, even it might not be the desired. For example, there is no standard defined on how to render <input> element, whether it should auto-detects the input text's directionality and uses that for rendering, or use the <input> element's directionality for rendering the input text. There are some discussions (comment #2, #7, #8, #10 ) in related WebKit issue. For example, there is no standard defined on how to render <selection>/<option> elements when either or both the element have 'dir' attributes defined. There is discussion (comment #2, #5) in related Webkit issue. The same goes for for script dialog text, <title> attribute etc. Aharon Lanin proposed additional requirement for BiDi in HTML for HTML5.
Milestone 9 (r72805):