#2610·lexical

Full bidirectional (RTL) support

Author: NirlahCreated Jul 7, 2022Updated Sep 2, 2026
Labelsenhancementcoretext direction

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.