11–20 of 75 posts
Although I guess I could render the JSON to HTML server-side and get the best of both worlds. Everything usually boils down to a question of caching something somewhere.
I've used Kurtz extensively and it's been brilliant. The only downside of all these block-based editors is that you can't easily create layouts where images float to the left or right of text. Well, you can create them but you don't get a WYSIWYG idea of what it looks like right in the editor. I can live with that!
I've explored all sorts of editors and Colonel Kurtz is the one that's worked best: Trix, Draft, TinyMCE, CKEditor, ContentEditable, ProseMirror - just off the top of my head.
This is really nice. Now HTML is not a concern anymore. Really fit the mental model of React. Will try this in my current project. Thanks you very much.
Make sure you try it in any browsers you want to support, especially mobile. That's where the dragons are. It also sucks to be in a position to say "lol sorry" to a user for being unable to do something in a major mobile browser when you could've gone with something more solid like ckeditor.
Curious how this stacks up against draft js?
Or slatejs. As I understand both have (or used to have) some serious problems with Android mobile. I don't see an explicit claim of Android/mobile support here either, which to me would be the killer feature.
Earlier quoted context omitted.
Make sure you try it in any browsers you want to support, especially mobile. That's where the dragons are. It also sucks to be in a position to say "lol sorry" to a user for being unable to do something in a major mobile browser when you could've gone with something more solid like ckeditor.
As i see, this editor only returns the blocks for you. How to render is upon you instead ? Or i miss something important here ?
The hard part I'm referring to is making the WYSIWYG editor. Contenteditable takes things a step further by having you (editor + plugin implementors) intercept every native event and then reimplement that logic yourself, especially between click, hover, and touch (mobile) and browser differences between the events.
Since you said you were going to try it in your current project, I just wanted to warn you. I learned this the hard way when using Facebook's Draft.js on a simple chat box input. We moved to either ckeditor or tinymce iirc because support was more polished all around.
To the best of my knowledge, Prosemirror has been most willing to prioritize mobile support, and currently has the best mobile browser coverage of the three most commonly mentioned modern contentEditable options (prosemirror, draft-js, quill). Unfortunately, building an editor with Prosemirror is a very hands-on process that requires you to make all the UI decisions and most of the UX decisions yourself, which isn't a great fit for most projects that don't need to innovate in the actual content creation side of things.
I would LOVE it if a batteries-included editor like this, which clearly had a lot of thought put into the UX and UI aspects, was built on the very-robust technical foundation of Prosemirror (or similar). There are a few efforts at this on GitHub, but nothing so far with more than one or two contributors that I've found. The backend of editor.js looks solid, but without any discussion of mobile IME support, and without the backing of big players like NYT [5], realistically I can only guess that mobile support for editor.js will end up similar to the well-intentioned but partially complete mobile support found in other smaller projects like quill, slate, etc.
[1] https://news.ycombinator.com/item?id=14417624
[2] https://github.com/codemirror/CodeMirror/issues/3403
[3] http://engineering.mindlinksoft.com/why-draftjs-doesnt-work-...
[4] https://github.com/ianstormtaylor/slate/issues/2062
[5] https://open.nytimes.com/building-a-text-editor-for-a-digita...
Every time I see a new contenteditable-based editor I'm reminded of this https://medium.com/content-uneditable/contenteditable-the-go...
I had been assigned to implement a rich text editor which was pretty close to what OP has posted, except that it a feature where the editable text had 'islands' of uneditable text sprinkled in-between. Sounds simple enough? Just add a nested element with contenteditable set to `false`. This worked well enough in Firefox and Chrome, but for some reason it wouldn't work in IE (surprise!).
After hours of scouring the internet, I found the solution[1], which was setting contenteditable to `true` for disabling the edit in the case of IE. The reason for this behavior? Nobody knows.
I still feel pangs of guilt for the poor sod who has to maintain that dumpster fire that I wrote as a fresh faced grad.
[1] https://stackoverflow.com/questions/7522848/contenteditable-...