Reinmar

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

Happy Global Accessibility Awareness Day, everyone!

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.

What's not true at all? That more powerful rich text editors need to rely on a tree structure?

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.

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

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.

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.

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.

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

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.

Hi! The author of this article here :) I hoped you liked it (cause your message can read both ways :D)

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 [1]). If you have any questions or you're curious about some particular aspects, please let me know :)

[1] https://ckeditor.com/ckeditor-5/

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

Totally agree. In fact, they even used HTML inside the "text" property so, in fact, they mix JSON with HTML which doesn't seem to make a lot of sense.

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

Which FOSS license? Because if it's a permissive one, like MIT, BSD or MPL, then you get results like we did with CKEditor 4:

From these thousands of businesses and millions of downloads, a very small group (less than 0,5%) decides to enter into business relations with CKSource.

Source: https://github.com/ckeditor/ckeditor5/issues/991

CKEditor (a rich-text editor) is this kind of really complex piece of software which requires years of experience and years of development. It's also a piece of software which is complex enough to scare people from contributing to it. So people use it for free and report bugs to you. That's all. With that conversion rate about 0.5% and a rather niche market, it's possible to slowly grow your business (as we did – CKSource is 40+ people today), but hard to keep up with the world.

Just to give a context – CKEditor 5 (which was written completely from scratch) required 5+ experienced developers working for more than 4 years right now. Therefore, for CKEditor 5 we chose GPL2+. We hope to have a more healthy paying/free users ratio. The future will show us if that's a good direction

BTW, you say that:

commercial licenses can be a serious pain to navigate in many companies

From my experience, it's actually the opposite. Companies like our commercial license because it's easier for them than going with e.g. LGPL or MPL and hoping they won't violate it.

It was even worse for CKEditor:

From these thousands of businesses and millions of downloads, a very small group (less than 0,5%) decides to enter into business relations with CKSource.

Source: https://github.com/ckeditor/ckeditor5/issues/991

However, the difference is that all CKEditor 4's plugins were open sourced and licensed under a permissive set of GPL2+/LGPL/MPL licenses. So the project was funded by a combination of support, SLAs and commercial licenses.

With CKEditor 5 (a completely new project) we chose GPL2+. I will be able to tell you how it worked for us in a couple of years

Ouch :( Unfortunately, mobile Safari's viewport is full of those issues.

I reported a similar one to the WebKit team a couple of months ago:

* https://gist.github.com/Reinmar/91c70d2882523f47da7c49805042...

* https://bugs.webkit.org/show_bug.cgi?id=191204

This is an issue with the viewport mechanics making it impossible to position anything in the viewport when the software keyboard is visible. This is something that every rich-text editor developer deals with and that's why none of them work really nice on iOS.

Chrome (Blink) behaves much better here – just like one would expect it to. This means that there's a pattern which Safari developers could implement in it too. Also, I talked about this with Safari's developer who worked on the current mechanism and I got the impression they weren't aware of how problematic the current implementation is for developers. So, big +1.

I'm not sure how long they can keep doing so. At what point it may affect iOS's reception in general?

From my own experience, making the app I'm working on (CKEditor 5 - a web based rich-text editor) compatible with mobile Safari is right now impossible. None of the RTEs work well in mobile Safari because of its quirks and bugs.

If Apple will overdo this (just like Microsoft did with IE6), that may affect iOS's usefulness. Sure, right now you can't build a business without your presence there, but there may be a breaking point. It's hard to imagine and I kinda doubt it will happen (I rather agree with the author of this article that Apple will invest enough to keep Safari alive), but it's a possibility. Microsoft screwed it up once, so can Apple.

You say that Mozilla will be well-positioned as an alternative to Google. That sounds realistic and I hope it will be able to team up with bigger companies which would like to compete with Google (instead of helping it).

However, that made me think about Brave (https://brave.com/). What are your thoughts about it? It's also privacy oriented, but it's actually built on top of Chromium. What is even more interesting, Brave was founded by Brendan Eich (the co-founder of Mozilla).

Amazing read! Very insightful and open at the same time. I've literally highlighted every other sentence in it. Thank you, Ferdy!

I basically went through the same thinking process myself. I'm a moderate idealist and would like Firefox to succeed because it's important for the web that there's no monopoly. However, my realist soul tells me that Firefox is losing badly and it's hard to tell where it's going to end. It's a pity that Microsoft didn't choose Gecko – I wonder if they even seriously considered it.

With Microsoft joining Chromium, we're slowly entering a duopoly of WebKit and Chromium. It's still a much better situation than the dark IE6 times. However, it's hard to tell whether WebKit (AFAIU, supported mainly by Apple and Samsung) will keep up with Chromium (Google and Microsoft) in a long term. I'm afraid that it will look like a Cold War's arms race – one of the parties will invest so much that the other will just lose economically (not being able to afford that many developers). Such economical wars make developers happy, because the web progresses very fast, but I think it actually leads to a monopoly.

Anyway, I'm still keeping my fingers crossed for Gecko. They do a great job there and perhaps will be able to partner with a big enough company to keep its pace and market share.

You're right. It took me over 5 years from the moment I assembled this PC to the moment I found the mistake ;)

Anyway, I don't think that anyone would actually think that I worked on this for 3 years. But when applied to software (to which this story lead me), I often hear "it took them 3 years to fix this". It's pretty much the same here. The bug was there, it caused serious issues (also with other systems), I applied various random workarounds and I spent a lot of time on it and yet, it got fixed by an accident much much later.

Thanks! A good UX was indeed one of our main goals and we weren't sure whether we're not overdoing this (again, the Netscape history ;|). But we kept in mind that simpler solutions already exist and it doesn't make sense to just copy them. That'd make the job easier, but we'd end up with the same issues that we identified in the existing platforms (annoying conflict resolution, stability issues, platform limitations to linear content – no tables, no nested blocks). So we risked taking the long path. The UX served as a compass and allowed making some reasonable shortcuts in some non-critical places. If we'd try to solve all possible issues that we've hit, we'd still be in the starting point :D

We've been there (although, in case of OT). When implementing CKEditor 5, we started with a linear model and just a couple type of operations (the usual set). At that time, we weren't able to transform that linear model to a tree model because conflict resolution based on that simple set of operations was too dumb. As I mentioned in the other comment about CRDT vs OT, we'd still consider having a linear + tree model duet, but so far it's purely theoretical discussion whether it has a chance to work.

Oh, that's really tempting :) Believe us! There are people in our team who would love to dive deeper into CRDT. We confirm that OT definitely has its problems. It's elegant at first but gets really dirty the deeper you dive into this... hole. Especially the undo feature adds to it a tone of complexity.

So, some of my colleagues see CRDT as a potential saviour. There was even a paper on CRDT for tree structures that we might use (can't find a link now). However, we'd rather go with a linear model for CRDT. That'd make it a bit easier on the CRDT level but it would require some really smart decisions about: types of changes, the structure of the linear model and how it is transformed to the tree model (that we need after all). We know, though, that without an actual implementation, it's just a theoretical discussion. Therefore, we started thinking whether we could add CRDT "below" our current tree model. That might allow validating the concept in a real-life. Can't wait to do that :)

BTW, in the meantime, we recommend this paper: https://arxiv.org/abs/1810.02137

It took 3 years for 20 people to build CKEditor 5 + collaborative editing plugins + a scalable cloud infrastructure for all this. What's more, unlike many others, CKEditor 5 itself has nearly 9000 tests (3x more than React) and won't disappear next year. We're already on this market for 15 years and plan to support CKEditor 5 for at least 8 years.

We haven’t yet seen any other complete real-time collaborative editing solution on the market (excluding Google Docs and Dropbox Paper which you can’t integrate with your application). And I think that it's not a coincidence that we're first here. This field is extremely demanding and we're one of the very few who have the experience in it.

We totally understand that there will always be the free option out there, but we're sure that those who opt to go with CKEditor precisely understand the benefits of what they're paying for.

Together with CKEditor 5 v10.0.0 we released plugins enabling real-time collaborative editing in CKEditor 5 :)

Check out the demo on https://docs.ckeditor.com/ckeditor5/latest/features/collabor...

Hey, Piotrek Koszuliński from CKEditor here.

As a matter of fact, we're involved in the W3C's Editing Task Force since the beginning. Me and Fred (the author of the blog post) were on the first meeting in Berlin back in 2014 and I've been in Paris the year after. Unfortunately, since then many meetings were held outside Europe and they were also concerned with more technical parts of the spec(s) to which it's harder for us to contribute. However, we still try to contribute as much as we can... but I have to say it's tough.

The problem is that this topic is vast and extremely complicated. Rich-text editing itself is complicated, but when you start considering all the languages (e.g. RTL mixed with LTR, IME), different types of devices and interaction models (software keyboards, block selection on touch devices), different OSes, clipboard, context menus, accessibility (!!), and what else is there, then you just want to quit.

In 2014 we believed in the contentEditable=minimal approach where contentEditable was just meant to provide an input/output layer. Even most of the browser people (all that I can remember) were positive about the idea. We were meant to get a cancellable `beforeinput` event and more reliable Selection and Range APIs. 3 years later and things moved forward (the event is available in some browsers), but so many topics are still open that it's hard to say what's the ETA for all of this.

For example, recently it turned out that IME is a bigger blocker than we thought. Android implements IME APIs in such a way which makes cancelling `beforeinput` impossible to handle on their side.

Simultaneously, there's a recurring idea to drop contentEditable completely and implement a completely new set of APIs. If you'd analyse how many APIs we're talking about you'd welcome contentEditable with open hands. I'm slowly starting accepting the fact that contentEditable needs to be replaced one day and that contentEditable=minimal approach may not be fully feasible, but I expect that we're talking here about next 10 years or more. There's no middle road here – either all the APIs are implemented and stable or contentEditable remains our only weapon.

BTW, I'd like to take this occasion to mention Johannes Wilm from Fidus Writer who's leading the Editing Task Force's work. Without him the whole thing would die sooner or later. We can all give feedback, but someone needs to lead the work and process feedback from all the involved parties.

Yes, that's true. The idea to separate the model and the view is as old as MVC itself. However, what matters here is how the model is actually implemented and what mechanisms it supports.

In CKEditor 5 we took perhaps the longest possible road so a tree structure with Operational Transformation support and couple of other goodies. It costed us a 3 years of work, but it was worth it. We proved the concept and validated the results by implementing the Letters app (https://ckeditor.com/letters/) which supports real-time colaborative editing for real (with selective undo, commenting, displaying selections of other users, etc.). We'll now be working on adding more features like e.g. tables support which rise the bar for the data model and the whole architecture even higher, but we're very optimistic seeing the results to far.

Yep, we do use contentEditable as an input source and also as the view to which we render (you wouldn't be able to reliably handle the keyboard otherwise).

I covered the "Can't it be avoided?" section in this article a couple of years ago: https://medium.com/content-uneditable/contenteditable-the-go...

tl;dr: Unless browsers will open for the Web multiple crucial features (such as IME, keyboard, selection, touch, on-screen keyboard, spellchecker, etc.) contentEditable is the only sane way to handle text editing.

There's an ongoing initiative to fix this situation but it's an extremely complicated topic. I wrote a few words about it in https://medium.com/content-uneditable/fixing-contenteditable... but later things got even more tricky. Since then I've been on W3C's meeting in Paris and contributed to many discussions about the standards and I can say that this whole topic makes even the most experienced browser people suffer when trying to solve it. Fortunately, 2 years later I can still say that things move forward. E.g. the beforeinput event landed in a couple of browsers.

I could never understand why people favour Markdown over HTML. Markdown is the worst idea when it comes to storing data. It's not standardised so there are dozens of incompatible flavours and incompatible Markdown -> HTML and HTML -> Markdown converters. Introducing Markdown to your app will eventually bring troubles but developers rarely notice this cause all seems to work initially when they test the simplest cases.

So, why did we create a Markdown data processor for CKEditor 5? (You can find a demo of it here: https://docs.ckeditor.com/ckeditor5/latest/features/markdown...) It was just to showcase that you can actually do that. But I'd never recommend it to anyone. HTML as a format is standardised and stable and there are even more tools to process it.

PS. There's the CommonMark standard, but it was created too late and its adoption is low.

PPS. We actually wrote an article called "A Standard for Rich-Text Data" – you can read it here: https://medium.com/content-uneditable/a-standard-for-rich-te...