10 ms·

Editor.js – Block Styled Editor

347 points by tortilla 8y ago

blunderkid 8y ago
Curious how this stacks up against draft js?
- baddox 8y ago
  Or ProseMirror, Slate, Quill, Trix, or probably a dozen other very similar contenteditable-based editor frameworks.
- jjdonov 8y ago
  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.
  - evangow 8y ago
    They're hard at work on Android support on SlateJS. https://github.com/ianstormtaylor/slate/issues/2062 https://github.com/ianstormtaylor/slate/issues/2062
    - baddox 8y ago
      We just upgraded our Slate version, and the relatively new Android support is sort of working, but still with a lot of bizarre and janky behavior.
      - thesunny 8y ago
        I implemented Android support on Slate. It is currently the first release and I will be committing time to fixing the remaining bugs starting within this month most likely.
        baddox 8y ago
        Thanks for what must have been a ridiculous amount of effort! It is already good enough that we re-enabled edit mode on Android.
  - johnchristopher 8y ago
    Why is Android a concern ? Aren't articles written and their layout tuned on a desktop/laptop anyway, at least for anything taking much longer than writing a tweet ?
    - true_religion 8y ago
      Articles yes. Blog posts not so much.
o_____________o 8y ago
Great! Now put this in a CMS that allows for custom React elements so we can get rid of Wordpress/Gutenberg.
stocktech 8y ago
I've been struggling with ProseMirror for the last 2-3 months. This looks amazing and I'm looking forward to replacing Prosemirror with it.
- wiktorn 8y ago
  Out of curiosity, what were the most irritating problems you faced there, that in the end you decided to start looking for a replacement?
revskill 8y ago
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.
- hombre_fatal 8y ago
  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.
  - revskill 8y ago
    As i see, this editor only returns the blocks for you. How to render is upon you instead ? Or i miss something important here ?
    - hombre_fatal 8y ago
      Implementing render(blocks) -> html is trivial. 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.
chinhodado 8y ago
Every time I see a new contenteditable-based editor I'm reminded of this https://medium.com/content-uneditable/contenteditable-the-good-the-bad-and-the-ugly-261a38555e9c https://medium.com/content-uneditable/contenteditable-the-go...
- as1mov 8y ago
  Heh, I remember a fun bug(?) I had found in IE while using contenteditable on my previous job. 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-false-inside-contenteditable-true-block-is-still-editable-in-ie8 https://stackoverflow.com/questions/7522848/contenteditable-...
- EGreg 8y ago
  I read this! And then we decided that the right thing to do for MOBILE is to completely AVOID native selections. The editor we built is way more clean than ANYTHING professional companies like Froala, Imperavi, TinyMCE, CKEditor and others have put out. But only for mobile touchscreens. 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: https://youtu.be/-DgaTwG1csc https://youtu.be/-DgaTwG1csc 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.
- saagarjha 8y ago
  Yeah, unfortunately this one breaks Emacs keybindings on macOS :(
andybak 8y ago
Why JSON-that-resembles-HTML rather than whitelisted-subset-of-HTML? Seems to throw away a huge amount of tooling and force an extra step on anything that wants to render the content? 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.
- xemoka 8y ago
  I think the idea is platform agnosticism. What if you're serving to a client that doesn't understand html? You'll need to interpret it somehow...
  - ComputerGuru 8y ago
    Text objects are apparently still HTML, I.e. HTML parsing is still required to understand the input.
- Ralfp 8y ago
  Every browser uses different markup to represent contents of contenteditable. One browser uses div for text and splits it into two when enter is pressed, other browser inserts <br/>, next one has paragraph, etc. ect. 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.
  - Reinmar 8y ago
    Still, that does not mean it cannot output HTML. CKEditor 5 implements a custom data model, works in the way you described (cancel native actions or extracts stuff from it, apply those changes to its data model and re-renders the DOM if needed), but it still outputs HTML. Thanks to that you don't need a processor to use that content on your page. Plus, there are cases where converting a custom data model to HTML is actually a tricky job (e.g. inline formatting) and even Editor.js chose HTML for those.
AlexMuir 8y ago
Two long established predecessors to this: Sir Trevor JS[0] and Colonel Kurtz [1]. 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. [0] https://madebymany.github.io/sir-trevor-js/ https://madebymany.github.io/sir-trevor-js/ [1] https://github.com/vigetlabs/colonel-kurtz https://github.com/vigetlabs/colonel-kurtz
- n8hunzaker 8y ago
  Maintainer of Colonel Kurtz here! It's super awesome to see positive feedback. Thank you! 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.
  - spiralx 8y ago
    I'm not familiar with your editor or block-based editors in general, but it looks like a basic version of a visual editor I used in WordPress a while back. Is there some reason you can't do it similarly to how that did it, by allowing a row to be split into columns, each of which can have a content element within it and can have it's width adjusted manually or set to fit to its content? If you used flex instead of floats it seems like you could have most of the functionality without the edge cases of floated elements.
- raffijacobs 8y ago
  Thanks for the sirtrevorjs link. Looking at the structure I was thinking how similar it is.
samradelie 8y ago
We were draftjs, but it got very slow on larger texts. We're replacing with slate but it lacks some very needed textnode manipulation. Glancing at the editor and api, wow. Can't wait to have something simple (content editable) but with strong api backbone. Congrats!!!
- Reinmar 8y ago
  Did you try CKEditor 5? It's a modern rich-text editing framework with a rich API. However, it also comes with a lot of polished and ready-to-use features. You can read more on: https://ckeditor.com/ckeditor-5/ https://ckeditor.com/ckeditor-5/.
  - bojanz 8y ago
    Since you mentioned CKEditor 5, I'll be bold enough to go a bit into off-topic. 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[1] 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)? [1]https://github.com/ckeditor/ckeditor5/issues/991#issuecomment-384995497 https://github.com/ckeditor/ckeditor5/issues/991#issuecommen...
    - Reinmar 8y ago
      Thanks for such positive feedback :) 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.
deleted 8y ago
[deleted]
phaedryx 8y ago
Sadly, when I see libraries in other languages I think "oh, nice! Well done!", but when I see JavaScript stuff I cringe, "oh no, are they reinventing the wheel again?" as my first reaction.
qrohlf 8y ago
I've been following this space for some time [1], and for me the constant struggle has been finding something that is both batteries-included, so I don't have to build a usable editor from primitives on projects where the core differentiator is not related to how content gets authored, and mobile-friendly, so that I don't have weird capslock bugs on iOS [2], completely broken Android support [3], and just general mobile weirdness [4]. 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 https://news.ycombinator.com/item?id=14417624 [2] https://github.com/codemirror/CodeMirror/issues/3403 https://github.com/codemirror/CodeMirror/issues/3403 [3] http://engineering.mindlinksoft.com/why-draftjs-doesnt-work-on-android/ http://engineering.mindlinksoft.com/why-draftjs-doesnt-work-... [4] https://github.com/ianstormtaylor/slate/issues/2062 https://github.com/ianstormtaylor/slate/issues/2062 [5] https://open.nytimes.com/building-a-text-editor-for-a-digital-first-newsroom-f1cb8367fc21 https://open.nytimes.com/building-a-text-editor-for-a-digita...
- neSpecc 8y ago
  Thanks for a feedback and links. 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.
manigandham 8y ago
Nice, added to the list of editors: https://gist.github.com/manigandham/65543a0bc2bf7006a487 https://gist.github.com/manigandham/65543a0bc2bf7006a487 Perhaps they should've used the MobileDoc standard instead creating another one.
- putlake 8y ago
  Nice! Could you please augment that list with links to the HN threads about the release of each? A list like that is the starting point but often the pros and cons are found in HN discussions.
  - manigandham 8y ago
    You can search HN for any relevant discussions: https://hn.algolia.com/ https://hn.algolia.com/
LoSboccacc 8y ago
this is very well done! too bad browser selection api will cause LOT of bugs of this kind https://streamable.com/0gc8j https://streamable.com/0gc8j
- neSpecc 8y ago
  Capture this. PRs is already on review. Thanks.
neals 8y ago
That pop-up when I click the 3 dots is way too slow, it's really annoying. Those buttons should probably be visible on hover. Or better still, just show them on the side maybe. It takes too many clicks to get work done. (IMHO)
- neSpecc 8y ago
  Heard you, thanks. Will work on this.
forkLding 8y ago
Has the backend crashed? The screen just keeps loading
haney 8y ago
Wagtail, a CMS system for Django uses a very similar abstraction to this for their StreamField[1] type and I've found it incredibly useful. It allows frontend services and backend services to easily implement custom types, and treats streams of content as a list of 'blocks'. [1]: https://docs.wagtail.io/en/v2.4/topics/streamfield.html https://docs.wagtail.io/en/v2.4/topics/streamfield.html
beders 8y ago
Great effort, thanks!
openbasic 8y ago
What about bold, italic, etc?
- greensoup 8y ago
  Either press the word combinations, ctrl+b etc, or select the text you want bold and there will be a popup. 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.
arciini 8y ago
Here's my take on this from playing with it a bit: - 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. [1] https://news.ycombinator.com/item?id=18998042#19000425 https://news.ycombinator.com/item?id=18998042#19000425
- sk221 8y ago
  Great summary! I've researched WYSIWYG editors recently and second this.
- xixixao 8y ago
  The performance on mobile doesn't look great for me (significant delay between key stroke and rendering, on iPhone X), also this particular page could be more responsive and mobile friendly. Otherwise I love the idea of block-based editor and clean output.
  - oatmealsnap 8y ago
    Yea, it was even causing my keyboard to lag. Keystroke queued up, but the key press state (enlarged visible letter above your finger) was really delayed.
  - arciini 8y ago
    You're right. I expect that they're reconciling with their model in JS on every keystroke. I know Quill does an interesting thing where the DOM is the canonical model, and the JSON model is actually derived from the DOM by a strict transformation. Because of that, it works a bit more naturally with many native mobile editor interfaces.
deleted 8y ago
[deleted]
houshuang 8y ago
People interested in block styled editors and new takes on editors should look at hax-the-web, a big effort using web components primarily designed for educational materials at PSU, but usable for so much more. It's quite amazing the flexibility that is possible - here's one recent video, there are many many more on his channel https://t.co/eXM6yBQA7h https://t.co/eXM6yBQA7h
viksit 8y ago
Couple of questions, - 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 https://editorjs.io/usage but that url seems to be broken.
- neSpecc 8y ago
  Hi from CodeX. 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.
martin-adams 8y ago
I seem to be deep in this type of problem on a project. I see they opted to use multiple content editable sections. This means that using the up arrow keys, when going between the sections the cursor jumps to the start of the block, then the last line of the preceding block. It's an interesting trade of than to use one large contenteditable section.
bengotow 8y ago
Hey! I maintain the Mailspring email client and I've thoroughly battle-tested SlateJS and DraftJS. I'd absolutely love if we could move to something with broader contenteditable support in the future (it's more or less impossible to allow people to paste AND EDIT arbitrary HTML in the former two.) A few questions if the author of the post is around! - 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!)
- gohabereg 8y ago
  Hello! I'm a maintainer of Editor.js. 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!
blunte 8y ago
From a data management and flexibility standpoint, I see why block editors are becoming popular with some people. But as a user, it feels like a downgraded experience. 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).
- raffijacobs 8y ago
  I agree for most of it. I'm the current maintainer of https://github.com/madebymany/sir-trevor-js 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.

347 points by tortilla 8y ago

blunderkid 8y ago

Curious how this stacks up against draft js?

baddox 8y ago
Or ProseMirror, Slate, Quill, Trix, or probably a dozen other very similar contenteditable-based editor frameworks.
jjdonov 8y ago
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.
- evangow 8y ago
  They're hard at work on Android support on SlateJS. https://github.com/ianstormtaylor/slate/issues/2062 https://github.com/ianstormtaylor/slate/issues/2062
  - baddox 8y ago
    We just upgraded our Slate version, and the relatively new Android support is sort of working, but still with a lot of bizarre and janky behavior.
    - thesunny 8y ago
      I implemented Android support on Slate. It is currently the first release and I will be committing time to fixing the remaining bugs starting within this month most likely.
      - baddox 8y ago
        Thanks for what must have been a ridiculous amount of effort! It is already good enough that we re-enabled edit mode on Android.
- johnchristopher 8y ago
  Why is Android a concern ? Aren't articles written and their layout tuned on a desktop/laptop anyway, at least for anything taking much longer than writing a tweet ?
  - true_religion 8y ago
    Articles yes. Blog posts not so much.

o_____________o 8y ago

Great! Now put this in a CMS that allows for custom React elements so we can get rid of Wordpress/Gutenberg.

stocktech 8y ago

I've been struggling with ProseMirror for the last 2-3 months. This looks amazing and I'm looking forward to replacing Prosemirror with it.

wiktorn 8y ago
Out of curiosity, what were the most irritating problems you faced there, that in the end you decided to start looking for a replacement?

revskill 8y ago

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.

hombre_fatal 8y ago
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.
- revskill 8y ago
  As i see, this editor only returns the blocks for you. How to render is upon you instead ? Or i miss something important here ?
  - hombre_fatal 8y ago
    Implementing render(blocks) -> html is trivial. 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.

chinhodado 8y ago

Every time I see a new contenteditable-based editor I'm reminded of this https://medium.com/content-uneditable/contenteditable-the-good-the-bad-and-the-ugly-261a38555e9c https://medium.com/content-uneditable/contenteditable-the-go...

as1mov 8y ago
Heh, I remember a fun bug(?) I had found in IE while using contenteditable on my previous job. 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-false-inside-contenteditable-true-block-is-still-editable-in-ie8 https://stackoverflow.com/questions/7522848/contenteditable-...
EGreg 8y ago
I read this! And then we decided that the right thing to do for MOBILE is to completely AVOID native selections. The editor we built is way more clean than ANYTHING professional companies like Froala, Imperavi, TinyMCE, CKEditor and others have put out. But only for mobile touchscreens. 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: https://youtu.be/-DgaTwG1csc https://youtu.be/-DgaTwG1csc 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.
saagarjha 8y ago
Yeah, unfortunately this one breaks Emacs keybindings on macOS :(

andybak 8y ago

Why JSON-that-resembles-HTML rather than whitelisted-subset-of-HTML? Seems to throw away a huge amount of tooling and force an extra step on anything that wants to render the content? 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.

xemoka 8y ago
I think the idea is platform agnosticism. What if you're serving to a client that doesn't understand html? You'll need to interpret it somehow...
- ComputerGuru 8y ago
  Text objects are apparently still HTML, I.e. HTML parsing is still required to understand the input.
Ralfp 8y ago
Every browser uses different markup to represent contents of contenteditable. One browser uses div for text and splits it into two when enter is pressed, other browser inserts <br/>, next one has paragraph, etc. ect. 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.
- Reinmar 8y ago
  Still, that does not mean it cannot output HTML. CKEditor 5 implements a custom data model, works in the way you described (cancel native actions or extracts stuff from it, apply those changes to its data model and re-renders the DOM if needed), but it still outputs HTML. Thanks to that you don't need a processor to use that content on your page. Plus, there are cases where converting a custom data model to HTML is actually a tricky job (e.g. inline formatting) and even Editor.js chose HTML for those.

AlexMuir 8y ago

Two long established predecessors to this: Sir Trevor JS[0] and Colonel Kurtz [1]. 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. [0] https://madebymany.github.io/sir-trevor-js/ https://madebymany.github.io/sir-trevor-js/ [1] https://github.com/vigetlabs/colonel-kurtz https://github.com/vigetlabs/colonel-kurtz

n8hunzaker 8y ago
Maintainer of Colonel Kurtz here! It's super awesome to see positive feedback. Thank you! 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.
- spiralx 8y ago
  I'm not familiar with your editor or block-based editors in general, but it looks like a basic version of a visual editor I used in WordPress a while back. Is there some reason you can't do it similarly to how that did it, by allowing a row to be split into columns, each of which can have a content element within it and can have it's width adjusted manually or set to fit to its content? If you used flex instead of floats it seems like you could have most of the functionality without the edge cases of floated elements.
raffijacobs 8y ago
Thanks for the sirtrevorjs link. Looking at the structure I was thinking how similar it is.

samradelie 8y ago

We were draftjs, but it got very slow on larger texts. We're replacing with slate but it lacks some very needed textnode manipulation. Glancing at the editor and api, wow. Can't wait to have something simple (content editable) but with strong api backbone. Congrats!!!

Reinmar 8y ago
Did you try CKEditor 5? It's a modern rich-text editing framework with a rich API. However, it also comes with a lot of polished and ready-to-use features. You can read more on: https://ckeditor.com/ckeditor-5/ https://ckeditor.com/ckeditor-5/.
- bojanz 8y ago
  Since you mentioned CKEditor 5, I'll be bold enough to go a bit into off-topic. 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[1] 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)? [1]https://github.com/ckeditor/ckeditor5/issues/991#issuecomment-384995497 https://github.com/ckeditor/ckeditor5/issues/991#issuecommen...
  - Reinmar 8y ago
    Thanks for such positive feedback :) 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.

deleted 8y ago

[deleted]

phaedryx 8y ago

Sadly, when I see libraries in other languages I think "oh, nice! Well done!", but when I see JavaScript stuff I cringe, "oh no, are they reinventing the wheel again?" as my first reaction.

qrohlf 8y ago

I've been following this space for some time [1], and for me the constant struggle has been finding something that is both batteries-included, so I don't have to build a usable editor from primitives on projects where the core differentiator is not related to how content gets authored, and mobile-friendly, so that I don't have weird capslock bugs on iOS [2], completely broken Android support [3], and just general mobile weirdness [4]. 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 https://news.ycombinator.com/item?id=14417624 [2] https://github.com/codemirror/CodeMirror/issues/3403 https://github.com/codemirror/CodeMirror/issues/3403 [3] http://engineering.mindlinksoft.com/why-draftjs-doesnt-work-on-android/ http://engineering.mindlinksoft.com/why-draftjs-doesnt-work-... [4] https://github.com/ianstormtaylor/slate/issues/2062 https://github.com/ianstormtaylor/slate/issues/2062 [5] https://open.nytimes.com/building-a-text-editor-for-a-digital-first-newsroom-f1cb8367fc21 https://open.nytimes.com/building-a-text-editor-for-a-digita...

neSpecc 8y ago
Thanks for a feedback and links. 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.

manigandham 8y ago

Nice, added to the list of editors: https://gist.github.com/manigandham/65543a0bc2bf7006a487 https://gist.github.com/manigandham/65543a0bc2bf7006a487 Perhaps they should've used the MobileDoc standard instead creating another one.

putlake 8y ago
Nice! Could you please augment that list with links to the HN threads about the release of each? A list like that is the starting point but often the pros and cons are found in HN discussions.
- manigandham 8y ago
  You can search HN for any relevant discussions: https://hn.algolia.com/ https://hn.algolia.com/

LoSboccacc 8y ago

this is very well done! too bad browser selection api will cause LOT of bugs of this kind https://streamable.com/0gc8j https://streamable.com/0gc8j

neSpecc 8y ago
Capture this. PRs is already on review. Thanks.

neals 8y ago

That pop-up when I click the 3 dots is way too slow, it's really annoying. Those buttons should probably be visible on hover. Or better still, just show them on the side maybe. It takes too many clicks to get work done. (IMHO)

neSpecc 8y ago
Heard you, thanks. Will work on this.

forkLding 8y ago

Has the backend crashed? The screen just keeps loading

haney 8y ago

Wagtail, a CMS system for Django uses a very similar abstraction to this for their StreamField[1] type and I've found it incredibly useful. It allows frontend services and backend services to easily implement custom types, and treats streams of content as a list of 'blocks'. [1]: https://docs.wagtail.io/en/v2.4/topics/streamfield.html https://docs.wagtail.io/en/v2.4/topics/streamfield.html

beders 8y ago

Great effort, thanks!

openbasic 8y ago

What about bold, italic, etc?

greensoup 8y ago
Either press the word combinations, ctrl+b etc, or select the text you want bold and there will be a popup. 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.

arciini 8y ago

Here's my take on this from playing with it a bit: - 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. [1] https://news.ycombinator.com/item?id=18998042#19000425 https://news.ycombinator.com/item?id=18998042#19000425

sk221 8y ago
Great summary! I've researched WYSIWYG editors recently and second this.
xixixao 8y ago
The performance on mobile doesn't look great for me (significant delay between key stroke and rendering, on iPhone X), also this particular page could be more responsive and mobile friendly. Otherwise I love the idea of block-based editor and clean output.
- oatmealsnap 8y ago
  Yea, it was even causing my keyboard to lag. Keystroke queued up, but the key press state (enlarged visible letter above your finger) was really delayed.
- arciini 8y ago
  You're right. I expect that they're reconciling with their model in JS on every keystroke. I know Quill does an interesting thing where the DOM is the canonical model, and the JSON model is actually derived from the DOM by a strict transformation. Because of that, it works a bit more naturally with many native mobile editor interfaces.

deleted 8y ago

[deleted]

houshuang 8y ago

People interested in block styled editors and new takes on editors should look at hax-the-web, a big effort using web components primarily designed for educational materials at PSU, but usable for so much more. It's quite amazing the flexibility that is possible - here's one recent video, there are many many more on his channel https://t.co/eXM6yBQA7h https://t.co/eXM6yBQA7h

viksit 8y ago

Couple of questions, - 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 https://editorjs.io/usage but that url seems to be broken.

neSpecc 8y ago
Hi from CodeX. 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.

martin-adams 8y ago

I seem to be deep in this type of problem on a project. I see they opted to use multiple content editable sections. This means that using the up arrow keys, when going between the sections the cursor jumps to the start of the block, then the last line of the preceding block. It's an interesting trade of than to use one large contenteditable section.

bengotow 8y ago

Hey! I maintain the Mailspring email client and I've thoroughly battle-tested SlateJS and DraftJS. I'd absolutely love if we could move to something with broader contenteditable support in the future (it's more or less impossible to allow people to paste AND EDIT arbitrary HTML in the former two.) A few questions if the author of the post is around! - 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!)

gohabereg 8y ago
Hello! I'm a maintainer of Editor.js. 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!

blunte 8y ago

From a data management and flexibility standpoint, I see why block editors are becoming popular with some people. But as a user, it feels like a downgraded experience. 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).

raffijacobs 8y ago
I agree for most of it. I'm the current maintainer of https://github.com/madebymany/sir-trevor-js 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.