- Works on mobile (like Quill, Prosemirror)
- Does not support collaborative editing (unlike Quill, Prosemirror)
- Has somewhat unique block-based editing UI - think Notion (the data models of most editors support this, but the default UI of editorjs is much more explicit about this)
- Not built on React (like Quill, Prosemirror, but unlike Slate and Draft)
The mobile support looks quite mature, and I think this could be a good competitor to Quill and Prosemirror for single-user editing.
Per my previous comments (1), I think for new projects, going with Prosemirror or Quill are still great choices. I've tried Draft and Slate and both of them have lacked good mobile support and collaborative editing.
Otherwise I love the idea of block-based editor and clean output.
Perhaps they should've used the MobileDoc standard instead creating another one.
When writing multi-paragraph prose, the first draft isn't always the final draft. Quite often there's some shuffling around of parts of the content. With blocks, the user can't highlight part of one paragraph and into part of the next one because of the artificial container boundary.
Perhaps with some well planned keyboard shortcuts and other UI improvements, the friction can be reduced. Maybe also it will require a change in the way some of us think about content (although I still object to the user needing to think of content in terms of its subtypes and storage structures).
I'm the current maintainer of https://github.com/madebymany/sir-trevor-js which we started in 2012. At the time we had a fully block based approach and migrated to more of a document based approach when medium.com gained traction.
Since then we've debated what's the best approach for cross block selection as now the expected behaviour is very much that of a text editor such as word rather than a block based editing tool which it started out as. A couple of years ago we embarked on a rewrite that saw us look for a solution to the problem that would solve this. Not just a block based selection, but a cursor based selection between blocks, but this never got to a level we were happy with.
I think with the evolution of online editing over the years and editors such as notion.so the approach they've taken with the multiple contenteditable elements is a good first step. Over time we'll see how far they are able to take it. Adding features such as cross browser support, undo / redo and keyboard navigation.
- Does EditorJS support nested blocks? Eg: can I make a list node that contains a list? Can I make a list that contains a blockquote? (DraftJS is a /linear/ set of block elements, making it very difficult to model complex documents - Slate's document model is a tree which is why pretty much why I chose it over DraftJS.)
- Does EditorJS have test coverage? What's the overall testing story look like? I'm not a big TDD person, but we've had a few stability issues with Slate (granted a slightly out of date version) that cause the document state to become invalid after certain edits and then subsequent interactions throw errors. (It's absolutely terrifying to have your text editor crash!)
Regarding to your questions:
- Editor.js doesn't support nested blocks. We keep structure flat and want Tools API to be as simple as possible for new developers. The target audience of the Editor.js is media and blogs, usually you don't need complex structure there.
However, you can implement some complex plugins for your needs, nested lists as example.
- We consider development of the editor very serious and understand importance of the test coverage. At the moment we don't have unit neither e2e tests but this is the one of our next steps on the way.
Thanks for your feedback!
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.
JSON is not here for resemblance, but for normalization. You force single presentation of things from start, and when user presses enter (or other text composition event happens) you prevent default action, update document model (JSON) and then update the HTML.
This approach is much more sane and predictable than trying to trust browser's HTML.
Being JSON makes it easier to render into other formats, too.
You can have a nice structured HTML and it will be as portable, as interoperable (if not more) as that JSON.
Another take on this (by my colleague from CKEditor team): https://medium.com/content-uneditable/a-standard-for-rich-te...
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, 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.
You reminded me that I was planning to refresh it a bit since it's over 3 years old now. I'd like to cover the rise of modern rich-text editors like CKEditor 5, ProseMirror, Draft.js and perhaps dive a bit into what we've learned when developing CKEditor 5 (because after 4 years of work it's actually out by now ). If you have any questions or you're curious about some particular aspects, please let me know :)
Really curious if that grasshopper(Draft.js) is stil green.
We are thinking of hiring a manager to license this to everyone using the other editors on their site (sites like BuiltWith can tell you entire lists of these sites) or just negotiate to give an unlimited / open source license to Froala / Imperavi themselves!
See for yourself:
Contact greg at the domain qbix.com if interested. It would be a commission based job, but can involve a lot of fun things like producing videos and websites w our team.
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.
CK is our workhorse for tons of sites, and we've struggled to come up with a good general pattern for editing horizontal layouts. We'd happily take suggestions, however. I'll admit it's one of the more awkward things with the editor.
If you used flex instead of floats it seems like you could have most of the functionality without the edge cases of floated elements.
Looking at the structure I was thinking how similar it is.
CKEditor 5 is an incredibly impressive endeavour, and I've been following it with great interest. However, one of the things that separates it from the competition is the GPL license, which makes it impossible to use the editor in a permissively-licensed (Apache2/MIT) open source project. Your founder has indicated a readiness to grant a custom license to such projects.
So, I'm wondering whether that is still the policy, and how that's been working out in practice. Have any projects taken you up on the offer? Have there been any unforeseen problems? What are the legal limitations imposed (on distributors/forks of the project, for example)?
Yes, the "Free for Open Source" initiative is up and running. For now, we didn't promote it a lot because we wanted to learn how it works, but from what I know, the custom license that we proposed is already used by a couple of projects.
Based on the feedback that we got so far, we're right now working on a simplified version of this license. Its initial version still had some restrictions which didn't work for Apache2/MIT projects with a commercial branch. Plus, it was simply too long for normal people :). We're removing these limitations. Once it will be polished, we will talk about it more officially on ckeditor.com.
- Are there any plugins to transform the saved output into HTML or other content (markdown)? Or does the user have to implement these?
- Whats the difference between this and the CodeX editor referenced in many places?
Edit: PS: The docs link to https://editorjs.io/usage but that url seems to be broken.
Currently we does not have ready to use implementation for converting JSON into HTML after saving. It is a trivial and specific task, that depends on plugins you use.
CodeX Editor is the previous "working" name of early version of Editor.js. We have decide to change name on beta-testing stage.
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 , 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.
We have done a lot of work on core stabilisation and API improvement. First version of editor.js is used for a while by local big (well, relatively) media projects — vc.ru, dtf.ru, tjournal.ru with the 200-500k DAU. This projects have UGC communities, so the Editor is using many times in a day. I mean most of our resources on the past stage was directed to the stability purposes.
Fully agree with you about the importance of UI and UX (and mobile adaptation) in our case. This is a next step we have start today. And this is a reason why it is an open source and free. We see many talented developers and the demand, so we will continue to work.
Anyway, we had big plans for mobile support in CKEditor 5. Then we started doing more research  and it turned out there are critical issues with how WebKit works. You can guess, you can try, but with a tone of hacks you still won't be able to guarantee a smooth UI and great UX.
Right now, we're in a state where:
* after spending several months on it, text editing is well supported on iOS and Android (including spellcheck and stuff) – we don't get any bug reports recently about that part,
* the default UI is not working great on smaller devices.
The sad part is – we don't have any bigger plans to address the latter. We have some smaller ideas for making the current UI more responsive, but there will still be fundamental issues that you will face when using it:
* The conflict between the native UI (the balloons/panels with paste/copy/cut/bold/italic) and the custom editor UI. I've been bringing that to the W3C's attention since 2015 and nothing happened since then (most recent topics: , ). Right now, I don't have the funds anymore to lobby for this (neither have anyone else, apparently), so those topics seem to be completely stale.
* Inability to display your UI and implement functions like scrolling to the caret in a reliable way on WebKit due to its broken viewport mechanics . I even talked about this with one of the Apple devs responsible for the current behavior and he agreed that there may be a problem (a good first step :D), but I got literally zero feedback after the last year's TPAC in Lyon when I presented this issue.
* And more...
IMO, it's due to those issues that we haven't seen a single editor (implementing more than some really basic functions) with a good and stable UX on both iOS and Android. Every solution I saw was flawed in one way or another. I'm not saying that it's completely impossible to build such a solution, but rather that, taken all the obstacles and moderate demand (desktop is still the main platform for rich-text editing), the ROI seems too low for anyone to invest enough in it.
Anyway, feel free to contact me (e.g. via https://twitter.com/reinmarpl) if you'd like to discuss this more.
 https://github.com/w3c/editing/issues/182 (my presentation from last year's TPAC)
I guess my point of frustration is to watch project after project toss itself at the task of implementing a nice Medium-ish desktop UI, announce a new "standard" for JSON-based rich document serialization, get mobile support about 80% of the way there, and then just... leave it like that.
I don't have enough data to make a firm statement, but I would bet with confidence that that if you include native mobile apps in the calculation (iOS Notes app, Google Keep, Wordpress Mobile), mobile rich text editing is either more prevalent than desktop, or on a strong upward trend that will overtake desktop text editing in the next two years. The popularity of hybrid devices like the iPad pro, where you have a desktop-class processor and screen size but an iOS IME is only going to boost those numbers.
Will try this in my current project. Thanks you very much.
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.
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.
Or better still, just show them on the side maybe. It takes too many clicks to get work done. (IMHO)
too bad browser selection api will cause LOT of bugs of this kind https://streamable.com/0gc8j
You`re limited on the selection though, thats kinda a bummer. In my opinion making a selection and allowing a few operations, like bold, delete, is worth it.