Lexical – a web text editor framework that powers Facebook

> This is no different than choosing a volunteer-based OSS solution

the big difference with a true volunteer based OSS solution, like for example, linux, is that there's many individuals involved. The decision making in that project then won't turn into what spolsky said. I wouldn't imagine the linux maintainers "rug pull", but i can imagine facebook doing a rug pull.

Clickbait title, what does that even mean for a text editor to "power" facebook

I've been migrating the Lexical codebase to TypeScript recently, especially since it was open-sourced. This was done for a few reasons, but if nothing else, we know TypeScript has a much wider adoption that Flow. Removing learning curves helps to encourage contributions from the community.

Hmm, just tried the playground in Firefox on Linux, it’s about as buggy as fancy things like this tend to be.

• Inserting emoji with my Compose key: some (e.g. U+1F641) get turned into image-backed emoji and then duplicated unless preceded by another image-backed emoji; some (e.g. U+1F928) get ignored and left as normal text.

• If I type an emoji that gets duplicated while inside a link (but not inside bold/italic), one goes where the caret is, and the other goes immediately before the link, and it leaves the caret there.

• The image-backed emoji are incompatible with inline text formatting: if you type them in the middle of formatted text, instead of ending up with the likes of text EMOJI text, you end up with text EMOJI text, and although you can subsequently apply the formatting so that it shows in the debug tree, it doesn’t change the HTML markup (e.g. subscript/superscript/underline/code should certainly be visible, and even italic and bold can change emoji rendering).

• If I select part of a link starting outside the end of a link (that is, go one character past the link and then press the Left arrow key—Firefox has valid caret positions for both inside and outside the start and end of an element, depending on which direction you came from, which my faint recollection was a major trouble point on WebKit many years ago, that you couldn’t do that and so literally couldn’t model various reasonable, kinda like multiple selection which is also Firefox-only and extremely useful on tables) and delete that, instead of just deleting the selected characters, it deletes the entire link. (As above, this seems to be specific to links, not affecting bold/italic.)

• Very early on (before I had done any editing at all) when I tried the time travel feature, I somehow activated the autocomplete popup on the words “The playground” by clicking or something, even though autocomplete was not turned on (I only confirmed that that was what it was, and not a spelling corrector, by later enabling it and typing “the”) and it was supposed to be read-only.

• Resizing table rows and columns is very buggy, with things like the grippies easily getting lost, the table-cell-action-button not updating its position, and it sometimes failing to act on mouse up. (Props for including the functionality, though, as it’s normally overlooked.)

• Clicking in table cells always moves the caret to the start of the cell rather than where you clicked, meaning you have to use arrow keys to get to the right place, and can’t select properly by mouse either.

• Pop-up menus don’t scroll with the document while open.

• Autocomplete popup doesn’t close when you move the caret by mouse, though they will no longer work if you click on them.

• Incidentally, who thought it a good idea to apply `list-style-position: inside`?

And this was from a fairly quick test. I found most of this stuff immediately and would expect to hit most of these issues in real life.

I honestly wish people would try to be less fancy with WYSIWYG components, because the web platform just isn’t well-adapted to it.

Writing a ContentEditable editor means learning the internal state machines and undocumented behaviors of every browser you support. There are many articles online about ContentEditable / rich text editing. This one is a classic https://medium.engineering/why-contenteditable-is-terrible-1...

The major issue for both Android and CJK input is dealing with “composition” of characters by an “input method editor”. https://en.m.wikipedia.org/wiki/Input_method

In English, usually it’s okay to assume one key press event = one letter input. The opposite is true on Android generally, and for CJK languages on all platforms. These use input systems (like handwriting) where keypresses never occur, or many keypresses compose to produce one character. There are also new rules for IME composition input like “you can’t touch the DOM or change the selection during composition or the input will cancel and your user will be mad”. It turns the problem from “Hard” difficulty to “Nightmare” difficulty.

The baffling thing on Android is that each keyboard (Gboard, Samsung Keyboard, Swiftkey, Simeji, Sogou, Naver) have different composition behaviors with different event patterns… and GBoard’s ENGLISH input is probably the most strange! It composes whole English words like they were Chinese characters, and it wants to compose SO badly it will move text selection from wherever the user tapped to the nearest English word. And as an added bonus on Android only, the browsers selection APIs report the wrong selection during different phases of the event flow. Hah. Like when you tap a key, Android will send a selectionChange event before the first input-related event, and that selectionChange will probably report some weird lie about the selection position.