Reinmar
Joined 12 years ago
Karma
268
Submissions
44
Member since
Dec 22
Recent submissions
Comment · 7 months ago
I feel we were quite lucky back in 2015 when we started rewriting CKEditor with RTC as a core requirement. At the time, OT seemed like the only viable option, so the choice was simple :)
What definitely helped too was having a very specific use case (rich-text editing) which guided many of our decisions. We focused heavily on getting the user experience right for common editing scenarios. And I fully agree that it's not just about conflict resolution, but also things like preserving position mappings. All these mechanisms need to work together for the experience to make sense to the end user.
This is an older piece (from 2018), but we shared more details about our approach here: https://ckeditor.com/blog/lessons-learned-from-creating-a-ri...
One clear issue with OT that we still face today is its complexity. It's nearly 8 years since we launched it, and we still occasionally run into bugs in OT – even though it sits at the very core of our engine. I remember seeing a similar comment from the Google Docs team :D
Comment · 1 year ago
Happy Global Accessibility Awareness Day, everyone!
Comment · 2 years ago
I agree. Yes, you can. Quill is the example here.
Actually, back in 2015 when we started prototyping CKEditor 5, we started with this approach as well. Our goal from the beginning was to combine real-time editing capabilities with an engine capable of storing and rendering complex rich-text structures (nested tables, complex nested lists, other rich widgets, etc.). We quickly realized that a linear structure is going to be a huge bottleneck. In the end, if you want to represent trees, storing them as a linear structure is counterproductive.
So, we went for a tree model. That got many things in the engine an order of magnitude harder (OT being one). But I choose to encapsulate this complexity in the model rather than make it leak to particular plugins.
In fact, from what I remember, https://github.com/quilljs/quill/issues/117 (e.g. https://github.com/quilljs/quill/issues/117#issuecomment-644...) is a good example of issues that we avoided.
I also talked to companies that built their platforms on top of Quill. One of them ended up gluing together countless Quill instances to power their editor and overcome the limitations of the linear data model but is now looking for a way to rebuild their editor from scratch due to the issues (performance, complexity, stability).
So, yes. You can implement a rich-text editor based on a linear model. But it has its immediate limitations that you need to take into consideration.
Comment · 2 years ago
What's not true at all? That more powerful rich text editors need to rely on a tree structure?
Comment · 2 years ago
Thank god I didn't question what josephg wrote regarding the text-based OT :D
I'm actually part of the team that built real-time collaboration for CKEditor 5. As the article says, we use a tree-structured representation for rich-text data and decided (many years ago) to go with OT. My guess always was that GDocs also uses a tree structure as the internal data model or that at least Google Wave did. I think I based this on a comment from a Google employee who summed up their OT implementation as hard to stabilize, even over many years.
I know it's possible to kind of represent rich-text data in form of a linear structure. This makes the implementation of the OT much much simpler. But then the editor itself becomes much more limited or you need to combine multiple instances of its model to represent more complex data. E.g., AFAIK Quill (mentioned in the other comment) does not offer stable tables implementation. Something that wasn't that big of a deal for us.
Comment · 3 years ago
> Yeah. Text based OT is pretty simple to implement, too. It’s about 200 lines of code, plus a simple network protocol.
Just for clarification, while OT for plain-text (linear model) might be simple to implement, OT for typical rich-text editors (like Google Docs) that need to rely on a tree-structured data model is a whole different story: https://ckeditor.com/blog/lessons-learned-from-creating-a-ri....
Comment · 6 years ago
> A real world implication is that if you want to add a new operation to a system (...) with OT, you can probably find a way to extend what you have to get it in there, with a painfully non-linear cost as you add more new operations
Exactly the experience that we have in CKEditor 5. OT is awfully complex. However, we can fine tune it for new operations and different scenarios of usage (e.g. undoing changes is one of them). With CRDT, at least to my understanding, we might've been limited to what we'd took into consideration on day one. Seeing how many things we learnt very late in the process (5 years so far, some documented in https://ckeditor.com/blog/Lessons-learned-from-creating-a-ri...) makes me thing that we'd sink the company twice already.
Comment · 6 years ago
We went with OT five years ago in CKEditor 5 and we have the same experience. While it would be tempting to try CRDT, it seems to come with too significant tradeoffs in our scenario.
My colleague wrote down our thoughts in https://ckeditor.com/blog/Lessons-learned-from-creating-a-ri....
The other aspect of CRDT that's in some scary is what @mdpye explains in https://news.ycombinator.com/item?id=24621113. With OT, if we get the corner cases right, we can tune and extend the implementation. With CRDT that might be game over.
Comment · 7 years 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.
Comment · 7 years ago
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...
Comment · 7 years 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.
https://twitter.com/reinmarpl