4 ms·
I just came here to write that I think this is THE right approach for wysiwyg editor. Having a full model of the document tree rather and working from that rath
by ingenter 10y ago
I just came here to write that I think this is THE right approach for wysiwyg editor. Having a full model of the document tree rather and working from that rather than sanitizing `contenteditable`. I expect this approach to automatically solve many problems that other wysiwyg editors have.
- amelius 10y agoProsemirror still uses contenteditable under the hood though. I actually wonder why that is the case.
- ingenter 10y agoTo be fair "React Draft Wysiwyg" is using contenteditable too, but it also builds a full model of the document.
- grayrest 10y agoIt handles the more complex (e.g. CJK) input methods. The alternative is a hidden text field and you have to put more effort into emulating the cursor (e.g. up arrow/down arrow). Regularly re-generating the underlying markup removes a large class of edge cases and cross-browser incompatibilities in exchange for not being able to use the browser's native undo. It's still a lot harder than you'd expect but it seems to be working for draft and prosemirror better than my attempt to normalize the cross browser differences and rely on the browser. P.S. I also came into this thread to endorse Prosemirror.
- benbriggs 10y agoI like and use Draft, but the separation of a document model from contenteditable is a feature of the editor frameworks mentioned above (as well as others like slate) and is not unique to Draft, or this implementation of an editor around Draft.
- jyotipuri 10y agoThanks your your insightful feedback.