Now I can navigate between these contentEditable areas while moving the caret position as you’d expect (mostly).

So now it can sorta feel like it’s one big contentEditable but it’s actually made out of composable parts that can be position:absolute’ly.

Next, it’ll be easy to lazy load parts as they scroll into view. The positioning will be a bit complicated as there should be XML elements mapped to blocks, tables, cells, nested lists, etc. so it’ll need a layout manager. The layout manager thing will be responsible for lazy loading, and simulating layout flow by positioning parts based on the preceding parts’ position / heights etc. Maybe it would have a minimap scrollbar too from the same layout data :shrug:

Hopefully these composable parts means it can load big XML files because the UI thread can avoid most of the work, and all the content data will be in a background thread web worker thing with messages to load / edit / delete nodes etc.

The composable parts approach has some downsides though like:

• how CTRL+F searching the DOM will only search the lazy loaded part of the document, so the workaround that (eg) Google Docs do is intercept that same keypress and display an in-page search box and then implement search in their own JS. The search results can be displayed in a custom way which arguably is an advantage but it’s still annoying to have to write it.
• how CTRL+A select all also needs to be faked… it would require messaging the worker thread to serialize and send back a string which would be copied into clipboard. It’s annoying to develop but it feels ok to use.
• probably other stuff too

every option has some downsides. i’m ok with these