I think the OP is kinda off the mark. The next step for web editor abstractions is not implementing layout engines so we can render page breaks correctly. It’s a library that separates handling input from rendering output. The biggest constricting factor with ContentEditable is that your rendered view also dictates how your input works. We need a library that handles all the user interaction and accessible, localized text input flawlessly but invisibly while integrating well with the OS. If we have that, developers can build their layout system on top or just use DOM layout without worrying about their DOM structure being compatible with ContentEditable input quirks across all the browsers, or their HTML changing in random ways under their feet.
There are a lot of problems with doing a hidden ContentEditable for input, which is what Google Docs does. Last time I looked, the input / focused DOM element was actually hidden inside the blinking caret. But that strategy is clumsy with assistive technology because the accessible bits don’t “line up” with the actual UI drawn to the screen. It also breaks some system conventions like smooth cursor movement when holding spacebar on iOS’s keyboard. You can try it in Google Docs and see what I mean.
Those kinds of issues are actually why Lexical (FB’s new text editor toolkit) doesn’t use hidden input according to Lexical’s author trueadm on Twitter (can’t find my citation). Those same issues also make us hesitate to move that direction in Notion’s editor.
If you want to use a custom “layout engine” implemented on top of the DOM today, you can use Skia CanvasKit (https://skia.org/docs/user/modules/quickstart/) or Flutter Web which is based on Skia. Although CanvasKit is kinda slow and text looks bad on iOS.
There are a lot of problems with doing a hidden ContentEditable for input, which is what Google Docs does. Last time I looked, the input / focused DOM element was actually hidden inside the blinking caret. But that strategy is clumsy with assistive technology because the accessible bits don’t “line up” with the actual UI drawn to the screen. It also breaks some system conventions like smooth cursor movement when holding spacebar on iOS’s keyboard. You can try it in Google Docs and see what I mean.
Those kinds of issues are actually why Lexical (FB’s new text editor toolkit) doesn’t use hidden input according to Lexical’s author trueadm on Twitter (can’t find my citation). Those same issues also make us hesitate to move that direction in Notion’s editor.
If you want to use a custom “layout engine” implemented on top of the DOM today, you can use Skia CanvasKit (https://skia.org/docs/user/modules/quickstart/) or Flutter Web which is based on Skia. Although CanvasKit is kinda slow and text looks bad on iOS.