-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Full bidirectional (RTL) support #2610
Description
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:
Screen.Recording.2022-07-07.at.10.54.24.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:
Screen.Recording.2022-07-07.at.10.57.01.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:
- Maintain the current dynamic evaluation of direction as the default behavior.
- Add support for manually toggling/setting the node’s direction.
- If a node has a
directionmanually set, it should be respected. (When parsing a serialized editor state, the current implementation dynamically evaluates the content, disregarding the provided configuration.) - 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.