3 ms·
The approach here is a bit novel i.e treat each block as a separate editor instance (contenteditable) and somehow wire-up cursor movements to behave as if it's
by lewisjoe 3y ago
The approach here is a bit novel i.e treat each block as a separate editor instance (contenteditable) and somehow wire-up cursor movements to behave as if it's one big editable area.
But it comes with its downsides as well. For example cross block selection doesn't work.
If the entire page is one big editable area, then it becomes difficult to embed complex blocks like "kanban views" and calendar.
I guess we should think beyond contenteditable at this point and separate rendering layer from input layer[1] - sort of like how Google Docs has built its editor.
But writing a rich text editor is not just a text-editing problem. It essentially needs you to build a layout engine itself (like webkit) that knows how/when to recalculate and draw the affected parts (render objects) when the rich-text changes. Why? because baking in tables and image-wraps and other complex resizable blocks affect other elements around/after it.
Bottomline: we need a custom built layout engine + text renderer + input handler(that respects accessiblity) + selection handler to build an absolutely powerful rich-text editor. I'd like to start a open source project in this direction.
[1] https://twitter.com/jitl/status/1649761057953415174 https://twitter.com/jitl/status/1649761057953415174
- jitl 3y agoNotion used this strategy until January 2021, when we rolled over to one-big-ContentEditable. I actually tried the tactic Affine is using, that is implementing drag-to-select gesture yourself and forcing that selection on the browser, but I hit a bunch of roadblocks on iOS and Android that made me abandon it and go with big-ContentEditable.
- julienr2 3y agoCurious about the issues you faced on mobile! At Slite I was part of the mobile team, and the editor is using Slate. So to make it work in React Native we had to go for a WebView (similar to what Notion uses), with all the downside it can bring.. I tickled with the possibilty to do a native adapter of Slate, but the fact that it's based on a content editable, makes it complicated to adapt in React Native.. I have the feeling that block approach might fit better a more native integration on mobile. It seems similar to what Craft does, isn't it ?
- jitl 3y agoMostly Android input being a hellscape, and wrangling React inside ContentEditable posing weird synchronization challenges with input method editors.
- egonschiele 3y agoOn the flip side, with individual contenteditables, you can be more confident you're not accidentally editing a block you didn't mean to.
- YousefED 3y agoFyi, I'm building an open source block-based editor @ https://www.blocknotejs.org https://www.blocknotejs.org that uses one large contenteditable and doesn't have those downsides you mention. It's built on top of Prosemirror. Would be interesting to see projects going beyond contenteditable for sure!
- deleted 3y ago[deleted]