Full bidirectional (RTL) support

[Nirlah]

The following is a short overview of bi-directional editing surfaces and my suggestion for improving Lexical’s implementation. (Continued from the Discord discussion)

Overview

Modern editing surfaces’ default behavior today is to support bi-directional content by setting the direction based on the first letter’s language. This can be seen in the current Lexical implementation, Apple Notes, Gmail, and Google Docs:

https://user-images.githubusercontent.com/1909713/177728347-054678d1-cf3e-47d5-817e-c5041ff144ef.mp4

One implementation detail crucial for longer-form and complex content (like a letter or an article) is maintaining the previous paragraph setting if the user manually sets it. Microsoft Office Word gets this correctly:

https://user-images.githubusercontent.com/1909713/177722676-d603b861-daad-42b4-8378-f053bc455fa9.mp4

The recordings demonstrate Hebrew, but the behavior is similar in Arabic.

Implementation Suggestions

The following are my suggestions for scalable bi-directional support in Lexical:

1. Maintain the current dynamic evaluation of direction as the default behavior.
2. Add support for manually toggling/setting the node’s direction.
3. If a node has a direction manually set, it should be respected. (When parsing a serialized editor state, the current implementation dynamically evaluates the content, disregarding the provided configuration.)
4. One (or both) of the following will allow composing more complex content (letter/article) without constant friction: 4.1. If the root node’s direction is manually set, it should be the default direction for child nodes. 4.2. When creating a following paragraph, if the previous paragraph has a manual direction set, it should be copied into the next paragraph.

[fantactuka]

If a node has a direction manually set, it should be respected. (When parsing a serialized editor state, the current implementation dynamically evaluates the content, disregarding the provided configuration.)

QQ: Why it would not respect manual direction in case of deserializing, e.g. if you save editor state and then init new editor with serialized state wouldn't you want to keep that manually set direction?

[Nirlah]

If a node has a direction manually set, it should be respected. (When parsing a serialized editor state, the current implementation dynamically evaluates the content, disregarding the provided configuration.)

QQ: Why it would not respect manual direction in case of deserializing, e.g. if you save editor state and then init new editor with serialized state wouldn't you want to keep that manually set direction?

@fantactuka Yes. The parenthesis describes the current Lexical implementation, which ignores the node’s direction value when deserializing.

[bilobom]

@thegreatercurve thanks for the mention , would you mind sharing how #2785 would solve this ?

My understanding is that direction is set on reconciliation based on text. If my analogy is correct , is there a way to disable this behavoir ? I think if this behavious is disabled then direction can be set by the editor container and all sub-paragraphs will inherit that.

// dir can be set manually by a toggling button, lexical consumers have controll over this
<div contenteditable="true" dir="rtl or ltr"> 
  // old paragraph will retain their direction, because they contain dir and rtl-classnames
  <p class="theme.paragraph theme.ltr" dir="ltr">English text</p> 
  <p class="theme.paragraph theme.rtl" dir="rtl">نص عربي او عبري</p>

  // newly created ones will not have dir or rtl-classnames when direction (on reconciliation) is disabled
  <p class="theme.paragraph">English text</p>
  <p class="theme.paragraph">نص عربي او عبري</p>
</div>

[milkrong]

what is status of this features?