Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Editor.js – Block Styled Editor

editorjs.io

Post reply on HN
Print view View original

61–70 of 75 posts

Re: Editor.js – Block Styled Editor

#61

Post by arciini »

xixixao wrote: post #58
arciini wrote: post #41

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 mobil…

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.

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.

Re: Editor.js – Block Styled Editor

#62

Post by putlake »

manigandham wrote: post #21

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

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.

Re: Editor.js – Block Styled Editor

#63

Post by redmorphium »

Reinmar wrote: post #49
Ralfp wrote: post #28

Earlier quoted context omitted.

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 , 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, u…

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 a…

JSON is quite nice compared to HTML, in my view. It's less verbose. Also, I like the flatness of Editor.js's data model.

Being JSON makes it easier to render into other formats, too.

Re: Editor.js – Block Styled Editor

#64

Post by blunte »

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).

Re: Editor.js – Block Styled Editor

#65

Post by ComputerGuru »

Ralfp wrote: post #28
andybak wrote: post #11

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.

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 , 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, u…

In all cases you override the default action and determine what content to generate. The format (JSON or HTML) is an entirely separate discussion.

Re: Editor.js – Block Styled Editor

#66

Post by ComputerGuru »

xemoka wrote: post #22
andybak wrote: post #11

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.

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...

Text objects are apparently still HTML, I.e. HTML parsing is still required to understand the input.

Re: Editor.js – Block Styled Editor

#67

Post by raffijacobs »

blunte wrote: post #64

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 th…

I agree for most of it.

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.

Re: Editor.js – Block Styled Editor

#68

Post by manigandham »

putlake wrote: post #62
manigandham wrote: post #21

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

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.

You can search HN for any relevant discussions: https://hn.algolia.com/

Re: Editor.js – Block Styled Editor

#69

Post by Reinmar »

qrohlf wrote: post #19

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 mob…

We've been doing quite a lot of research around mobile support in the early phase of working on CKEditor 5. We knew from our past experience that on mobile devices (especially smaller ones) you need a dedicated UI, rather than a responsive version of the same UI that you use on the desktop. When the software keyboard is visible (+ when you have autocompletion bar above the keyboard) there's really not much space for your UI and the text that you want to edit. It means that you need really good control over what's happening on the screen in order to be able to implement a reliable UI.

Anyway, we had big plans for mobile support in CKEditor 5. Then we started doing more research [1] 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: [2], [3]). 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 [4]. 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.

[1] https://github.com/ckeditor/ckeditor5-design/issues/149

[2] https://github.com/w3c/editing/issues/176

[3] https://github.com/w3c/editing/issues/182 (my presentation from last year's TPAC)

[4] https://gist.github.com/Reinmar/91c70d2882523f47da7c49805042...

Re: Editor.js – Block Styled Editor

#70

Post by Reinmar »

bojanz wrote: post #52
Reinmar wrote: post #40

Earlier quoted context omitted.

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/ .

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…

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.

Post reply on HN