11 ms·

CKEditor 5: New approach to rich text editing on the web

219 points by davidpolberger 9y ago

donatj 9y ago
Interesting. That's always the way I thought it should be done, with a separation of display and structure. I used to work with a developer who maintained and actually made a decent chunk of change licensing out a very popular rich text editor developed before ContentEditable was even a twinkle in the browsers eyes. We used it pretty heavily within the company as well. Knowing first hand the horrible feats of iframe content string manipulation that had to be done to make an RTE work in Netscape and IE5.5, ContentEditable seemed like a DREAM. Ends up there's still a demo up for it, and it almost entirely still works! https://kevinroth.com/rte/demo.htm https://kevinroth.com/rte/demo.htm
- dualogy 9y ago
  Man, sites like this make me nostalgic =) https://kevinroth.com/projects/ https://kevinroth.com/projects/ gonna have to check out that ASP 3 stuff..
- CitizenKane 9y ago
  Oh man, I worked with Kevin a long time ago in my first web dev job. I remember this existing even at that point. Cool to see it here, haven't thought about these things in a long time.
atonse 9y ago
Looking at all these editors makes me feel good about having chosen mobiledoc 18 months ago for my ember app. I don't know if mobiledoc pioneered this approach of separating the data model but it was the first time I saw it and it felt right. Glad to see so many editors do this now.
- jhchen 9y ago
  I’m the author of Quill and I will attribute my decision to David Greenspan of Etherpad. Not sure if they are the first but it certainly predates all the examples I know of.
  - phirschybar 9y ago
    I just discovered this. Very cool!
- Reinmar 9y ago
  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/ 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.
  - atonse 9y ago
    Congrats to you and your team :) Developers (and users as a whole) only benefit from having more great editors to choose from.
dgreensp 9y ago
It still uses contenteditable, though, like Quill and ProseMirror, which also use a custom data model and ops. It sounds like CKEditor has caught up to have this kind of architecture too. Not to trivialize this accomplishment. All three are impressive feats of engineering and design.
- wakeywakeywakey 9y ago
  Can you point to where contenteditable is used? I was not able to see the attribute when inspecting the demo source.
  - jameskilton 9y ago
    https://ckeditor5.github.io/ https://ckeditor5.github.io/, inspect the content editing div itself, it's there. One thing I've realized playing with a ton of different editors is that contenteditable gives you one very important feature that you can't fake yourself: access to the browser's spell check and corrections. It's possible that CKEditor ignores everything else about contenteditable, but turns it on just for red squigglies.
    - mook 9y ago
      Spellcheck and corrections can be faked, I think, if you decide to compile your own hunspell (or whatever). IME (i.e. entering text for languages that do not have a one-to-one mapping of key press to character), though, is a lot harder; you have no idea what languages the user has configured, and showing _everything_ in a list is impractical.
      - mwcampbell 9y ago
        Not only IMEs for various languages, but also alternative forms of input such as speech recognition.
      - steadicat 9y ago
        Few people seem to know about Composition Events: https://w3c.github.io/uievents/#events-compositionevents https://w3c.github.io/uievents/#events-compositionevents Using those, implementing IME should be relatively easy. The events tell you which partial characters to show, and which completed characters to insert.
zschuessler 9y ago
Looking great for a first release! The demo is smooth, well done. Seems like there's a good framework in place to catch up to the competition. I'd switch away from TinyMCE or Summernote if there was a component/widget system that worked well. Writing custom behavior for any HTML editor is painful, and none of them have a big use case in mind: custom layouts. SiteOrigin's Page Builder for WordPress is cool: https://wordpress.org/plugins/siteorigin-panels/ https://wordpress.org/plugins/siteorigin-panels/ I wanted something (Free or paid) like what's shown in the above video, that's independent of WordPress. Couldn't find a darn single one, if you can believe it. I'm stuck with Summernote + workarounds to get something similar for a Laravel project of mine.
- deleted 9y ago
  [deleted]
- pbowyer 9y ago
  > I wanted something (Free or paid) like what's shown in the above video, that's independent of WordPress. Couldn't find a darn single one, if you can believe it. I can, because I've been looking for one. I believe there's a market for well done components like this: * Drag and drop page component builder (think Leadpages, Unbounce, SiteOrigin Panels) * Drag and Drop email builder (a la MailChimp et al) There's no need for every SaaS and startup to build their own - better to have a component (or even a dedicated service to integrate) to provide these JS-heavy timesinks than waste time while validating the idea creating them.
  - slig 9y ago
    > Drag and Drop email builder (a la MailChimp et al) Have you seen this? https://github.com/unroll-io/react-email-editor https://github.com/unroll-io/react-email-editor was released recently.
    - leesalminen 9y ago
      Wow, this is exactly why I read HN. I was Googling for exactly this yesterday. Thanks much!
bluetwo 9y ago
I'm a happy CKEditor 4 user, but let me know when this gets to 5.1.1. With so much rework, I just can't see myself rolling the dice and rolling this out right away! Congrats, though. Seems like an ambitious three year long project that you actually pulled off!
phirschybar 9y ago
Is the output just a giant blob of HTML? If so, I don't see what this does to solve what I see as the main problem of WYSIWYG editors... a terrible end-format for stored content. I got my hopes up when reading the intro that we would see a more structured output (not just the underlying in-browser data model). I would love to see a WYSIWYG output a JSON structure with markdown content. Not to minimize what appears to be a massive and successful effort! I just feel like HTML is a completely inflexible and rigid way to save content.
- justinator 9y ago
  The demo video at the bottom of the page shows that it can output to Markdown easily.
  - Reinmar 9y ago
    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.html 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-text-data-4b3a507af552 https://medium.com/content-uneditable/a-standard-for-rich-te...
- dotancohen 9y ago
  > ... the main problem of WYSIWYG editors... a terrible end-format for stored content. In many cases having the editor store HTML internally is the best solution, especially if the output will eventually be HTML anyway. Think of a Wordpress post submission page, or a website comment page.
frik 9y ago
"Most of the editors out there are based on ContentEditable, including CKEditor 4 and its previous versions. But ContentEditable is bad and ugly, though. It’s implementation among browsers is not standardized and its behavior for end users is often out of control" Yes, please W3C, Google, Mozilla, MS, Apple do something! Improve ContentEditable or create a new better standard for it!
- marijn 9y ago
  People [1] are working on this, but as usual with standards processes, it's slow and there's constant pushback from browser implementors. [1]: https://www.w3.org/wiki/Editing_Taskforce https://www.w3.org/wiki/Editing_Taskforce
- Reinmar 9y ago
  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.
williamstein 9y ago
I tried to use the Letters demo on my iPad Pro 10.5 and it wouldn't even let me try. I can't remember hitting another website in months that flat out denied "mobile" access like that.
- wiktor_walc 9y ago
  I'm sorry for this, but please note that this was a conscious decision to show products at the current state. We wanted to give the voice to the community to help us prioritise the development as soon as it makes sense. If we showed everything to the public once its fully ready (having all the nice to have features in place, brilliant support for mobiles), you would have no chance to let us know, for example, how you would like those features to behave etc. How exactly do you see the mobile support and so on. We did not want to blindly copy CKEditor 4, adding just the new architecture to it.
tonyspiro 9y ago
Froala is still my WYSIWYG editor of choice https://www.froala.com/wysiwyg-editor https://www.froala.com/wysiwyg-editor
- onurozkan 9y ago
  Both froala and reactor are pretty expensive products imo. They are really good editors and i believe they both worth it, but i would prefer cheaper or opensource alternative.
smacktoward 9y ago
ContentEditable was supposed to bring us a world where things like CKEditor no longer needed to exist. What on Earth happened? HTML5 has pushed the web platform so far forward from where it was back then; how did this one little corner of it end up stagnating?
- lstamour 9y ago
  ContentEditable never really specified much of a cross-platform standard API. If we wanted to replace CKEditor and its ilk, we should have pushed for a standard spec on textareas with rich structured editing support for a variety of formats (Markdown, reStructuredText, HTML, etc.) But that would then require standardizing structured text formats and/or figuring out how to add extensible functions, what to do with copy and paste especially from third-party apps, how should drag and drop be handled, what about saving, auto-saving, how should you add styles to a drop-down list to let users pick their own fonts, font-sizes, etc. These are complicated things to get right, often site- and implementation-specific, and contenteditable allowed for direct text manipulation and editing (with spell check and native text cursor flickering) within HTML, which is good enough to build your own rich editing interfaces around. So, it would be going too far to say ContentEditable was supposed to put these RTEs out of business. In fact, I would argue that Markdown's popularity has done more to put RTEs out of business recently, and that block-based, template- or widget-integrated text editing is the future, and where these tools' APIs are headed.
- onurozkan 9y ago
  We were too busy with js framework hypes :(
braindead_in 9y ago
Is there any editor which mimics the look and feel of Google Docs or MSWord?
- johndoe90 9y ago
  AFAIK CKEditor has theming support and one of bundled themes is MSWord.
- onurozkan 9y ago
  might work for you. http://jejacks0n.github.io/mercury/ http://jejacks0n.github.io/mercury/ for complete wysiwyg editor list; https://github.com/cheeaun/mooeditable/wiki/Javascript-WYSIWYG-editors https://github.com/cheeaun/mooeditable/wiki/Javascript-WYSIW...
  - edwinyzh 9y ago
    mercury sounds very good, too bad it seems to be abandoned.
sideproject 9y ago
Rather than using an all-inclusive editor like CKEditor, Froala or Redacted, I've been thinking a lot about a "block" based content creation like one that is available on https://www.notion.so https://www.notion.so http://madebymany.github.io/sir-trevor-js/example.html http://madebymany.github.io/sir-trevor-js/example.html https://www.froala.com/pages https://www.froala.com/pages (Looks like Froala also gives a block-based design in addition to their rick text editor) As we continue to insert and embed a variety of content types into these editors, I feel like this approach is more suitable. Any thoughts?
- manigandham 9y ago
  It's really all the same, HTML is already a component-based system but the parsing and tooling for it is poor when used through javascript. Maybe WebAssembly will change that but using a content-block approach is definitely a way to get around some of the complexity. Medium's editor uses a similar approach, probably the most common and there's Mobiledoc which is a standardized JSON format and editor framework: https://bustle.github.io/mobiledoc-kit/demo/ https://bustle.github.io/mobiledoc-kit/demo/ Side note, list of various editors: https://gist.github.com/manigandham/65543a0bc2bf7006a487 https://gist.github.com/manigandham/65543a0bc2bf7006a487
  - jordanlev 9y ago
    I do a ton of work with CMS's, building sites for non-technical clients who manage their site without much knowledge of HTML, CSS, or any coding/encoding (even markdown would be a bit much for some of my users). The big win that you get with a block-based system (as opposed to 1 big chunk of HTML) is that it allows us to build out the content editing interface in a way that is very "guided" for the user... like, if there is a photo gallyer, we have a repeating list of slides and they have fields for a photo and a caption. Then on the front-end we can build our HTML+CSS markup around those specific fields. You can't do that easily with 1 big chunk of HTML.
    - manigandham 9y ago
      Right, that's what I mean about HTML tooling. It's a fine data format but DOM manipulation isn't very good compared to a JSON data structure with native integration into javascript and more universal parsing ability. The mobiledoc format is a good start at standardization.
polskibus 9y ago
Can anyone tell whether CKEditor 5 approach differ from draftjs? If so, what are the pros and cons of each?
- onurozkan 9y ago
  afaik, you cant use draftjs projects like slate, react-rte (both of them awesome) with another framework like vuejs or angular. and you need to store your content as json or you should write parser for each custom block you defined.
- madhato 9y ago
  Big con for draftjs is it doesn't support Android.
  - polskibus 9y ago
    I didn't know that, I thought it did. What do you recommend as an alternative to draft that works well on mobile? Do you know if draftjs will fix this bug?
NicoJuicy 9y ago
I recently heard of CKEditor because of the dev log on tweakers.net ( a popular dutch news website).. They mentioned CKEditor, so they actively use it. Here's the link: https://tweakers.net/plan/1385/finetunen-van-de-lay-out-en-hands-on-development-iteratie-117.html https://tweakers.net/plan/1385/finetunen-van-de-lay-out-en-h... ( dutch)
jasonkester 9y ago
It's got to be tough spending a career working on ContentEditable. I don't know how these guys handle it. Not only do you get to spend all day every day wading through the impossible pile of bugs, contradictions, mutually exclusive implementations and downright wackiness in the thing itself (did it seriously just allow the selection to include the opening DIV tag of the contenteditable itself???), but you get to have the same conversation every day with developers who haven't ever used ContentEditable and therefore consider it to be trivial. "Why are you implementing the caret in javascript? Haven't you heard of ContentEditable?" "Why is your simple WYSIWYG editor component seven megabytes of javascript? Wouldn't it be better to just use ContentEditable and be done with it?" I only had to work with the technology for a few months. Years ago. And I'm still scarred today. Props to these guys for sticking it out!
- Tade0 9y ago
  Former member of the CKE team here. Three words: it was hell. The CKE people are some of the most hard working devs I've ever encountered in my life. I still find it funny how making little details like backspace/delete key behavior work is such a gargantuan task. And almost nobody gets it right.
  - nicoburns 9y ago
    I actually applied to CKE as my first job as, having made my own WYSIWYG editor [0] as a side project while I was at school, it seemed like something I had experience of. Never heard back from them: sounds like I dodged a bullet then! [0] https://github.com/nicoburns/ghostedit https://github.com/nicoburns/ghostedit
    - Tade0 9y ago
      I guess it was probably because(to my knowledge) only recently they started hiring junior developers. Anyway it was a hard and thankless job, but during these almost two years I learned a lot about having an, um, work ethic and doing things to the best of my ability. Also my current job looks really easy in comparison.
Vinnl 9y ago
The new release looks really nice, congrats to the devs. Although I haven't looked into it too deeply, the new editing model made me think of Draft.js [1], which might be interesting to some people as well. [1] https://draftjs.org/ https://draftjs.org/
marijn 9y ago
The "end of contentEditable" spin in this is weird. CKEditor 5 uses contentEditable. And that's a good decision—getting bidirectional text, IME, touch selection, spell-check, and screen reader support right without contentEditable, while possible, would require you to reimplement a _lot_ of browser functionality, which would necessarily lead to a blowup of complexity and download size. So sure, the new CKEditor does more or less what Quill, Slate, ProseMirror, and most other modern WYSIWYG components do—it separates its data model from the editable DOM. That's good, but not new.
- amelius 9y ago
  I'm wondering, how does Google Docs do it? And how do they achieve having a reasonably compact size?
  - marijn 9y ago
    They appear to have reimplemented most of these things, doing their own layout entirely etc. I wouldn't call google docs compact, but indeed, it's also not overly bloated, and it handles corner cases well. It'd be interesting to know more about its architecture.
- igravious 9y ago
  I can't find where in the codebase they employ contentEditable. Are you sure they still use it? Here is a GitHub search: https://github.com/ckeditor/ckeditor5/search?utf8=%E2%9C%93&q=contentEditable&type= https://github.com/ckeditor/ckeditor5/search?utf8=%E2%9C%93&... 3 Markdown documents, one JSON doc.
  - marijn 9y ago
    Focus a demo editor [1] and inspect `document.activeElement` in the console. You'll get a parent div of the content whose `contentEditable` attribute is true. [1]: https://docs.ckeditor.com/ckeditor5/latest/examples/builds/classic-editor.html https://docs.ckeditor.com/ckeditor5/latest/examples/builds/c...
exikyut 9y ago
Nobody's asked this, so: I've been fascinated with operational transformation for some time, but I haven't found anything that breaks it down into understandable steps. I vaguely recall that last time I poked around I found an extremely high-level algebraic breakdown that made no sense, and only after a _lot_ of digging was I able to turn up an actual example implementation that wasn't 100% useless (because contextless) theory. I fear that understanding OT is a case of for example spending 6 months reading Etherpad.
- manigandham 9y ago
  Try this video: https://www.youtube.com/watch?v=pMMDVphop40 https://www.youtube.com/watch?v=pMMDVphop40 One of the best overviews covering CRDTs and OTs, especially in the context of collaborative editing.
- pjasiun 9y ago
  6 months is a very optimistic scenario ;) A guy responsible for OT in Google Wave wrote once that he spent 5 years on it and it still does not work well in all cases. After 3 years of struggling to get it right, we know what he meant. Anyway, I believe that you can find a good entry point to OT here: http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation http://www.codecommit.com/blog/java/understanding-and-applyi.... It gives a nice overview of the problem – in a human-readable language – but it’s only the beginning of the journey. The original OT implementation has been designed for linear documents – texts. It does not fit very well with tree structure – you don’t want elements (tags) to intersect after resolving collision. It also does not fit undo where the order matters. For sure, operational transformation is not a closed subject, which you can just learn. It is an open problem with many cases still unsolved. If you are looking for a good topic for a thesis, I would recommend it :)
  - exikyut 9y ago
    > 6 months is a very optimistic scenario ;) Oh. > A guy responsible for OT in Google Wave wrote once that he spent 5 years on it and it still does not work well in all cases. After 3 years of struggling to get it right, we know what he meant. ...Wow, I see. (As an aside, I think it's really sad Wave's "cool" UI was never properly released.) > Anyway, I believe that you can find a good entry point to OT here: http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation http://www.codecommit.com/blog/java/understanding-and-applyi.... It gives a nice overview of the problem – in a human-readable language – but it’s only the beginning of the journey. I actually think this is one of the articles I found a while back. I agree that it's very thorough and in-depth, and, uh, I've managed to get slightly further into it before I started hitting PgDn repeatedly and my eyes glazed over than when I read this a few months ago! :) > The original OT implementation has been designed for linear documents – texts. It does not fit very well with tree structure – you don’t want elements (tags) to intersect after resolving collision. It also does not fit undo where the order matters. Ooooooooh yowch. > For sure, operational transformation is not a closed subject, which you can just learn. It is an open problem with many cases still unsolved. If you are looking for a good topic for a thesis, I would recommend it :) Hah! When I was exploring OT a few months ago I also explored alternatives such as realtime diff/match/patch into a model held in server memory. The simplest way to do this ultimately stores approximately documentSize*clientCount for every single document. That lets me keep an exact copy of every client state on the server, letting me tag updates with the hash of what the document should now look like. For small-scale projects the massive-but-not-concretely-exponential memory requirements of such an approach is somewhat out of control but not completely unmanageable: 1000 documents of 1MB each being edited by 20 clients each requires 20GB of RAM. (But my first guesstimate of sane limits - 10000 documents and 500 clients - would require 5.2TB though, haha.) Hmm. I just realized... some of the buffer architectures commonly used in text editors might be usable to implement server-side deduplication. Or... you could even probably just implement a copy-on-write scheme. Either would probably be an effective design win because (in the contemporary/common case) all clients editing a given document are generally seeing a 99.99%-accurate representation of that document relative to other users; if the network is good, there's only really a few characters' difference between users. OT feels like architectural overkill at the fundamental level, but I know that's just my overwhelmedness with the mental models required and the sense of "does it really have to be this hard?". I recognize that it really is that tricky, and kudos for keeping at it and then turning around and making the result open source! :D
bfu 9y ago
Font hinting went on a vacation on those pictures
PythonicAlpha 9y ago
What about Trix? Froala was already mentioned, I also heard about an editor namend Trix, that also claims not to use ContentEditable. http://trix-editor.org/ http://trix-editor.org/ Any experiences with that?
- ivanhoe 9y ago
  Actually they say: "Trix sidesteps these inconsistencies by treating contenteditable as an I/O device". They use it to capture the input, which they then process and pump it back into the contenteditable. So technically speaking they do use it, just in a weird way.
sandGorgon 9y ago
I wish there was an official react build for this. I had tried sometime back, but the integration with react fiber was a little tricky and kind of gave up.
chenglou 9y ago
I don't see many people talk about Apple's approach to text editing, on iCloud.com Pages. They use svg and it allows them to achieve some pretty fancy effects. Anyone experienced with this method?
- madhato 9y ago
  That is pretty neat. They use an invisible content editable field that moves to where the caret is placed. The content editable only contains the current word or selection. Text typed into the content editable is rendered into SVG elements. Unfortunately that doesn't allow a browser's spellcheck to work so they had to implement their own. iCloud Notes works in a similar way but it renders to canvas elements instead of SVG. Also doesn't provide spellcheck.
rkagerer 9y ago
Such nostalgia! I remember playing with this over a decade ago when it was still called FCKEditor. Kudos, Fred and team! (If we're doing show and tell, my old quick and dirty prototype for a structured FAQ editor still mostly-works under Firefox http://www.googlemappers.com/dev/prototypes/faq/template.htm http://www.googlemappers.com/dev/prototypes/faq/template.htm)
davidpolberger 9y ago
We have selected CKEditor 5 for our SaaS application for the following reasons: * We need to implement a custom user interface and CKEditor 5 makes this easy. Its modular nature enables us to build a custom "headless" bundle using Webpack. Keystroke handling is currently tied to the CKEditor 5 user interface, though, which is problematic as you don't want to reimplement what the Enter key does when editing, say, lists or block quotes. The team is actively looking into this issue, though, and it is possible to use a custom user interface while still benefiting from CKEditor's keystroke handling using a hack I documented here[1]. * The output format is (very clean) HTML. If we ever change our implementation to use another rich text editor, we don't want to write a server-side migrator moving user content from one editor format to another. Also, HTML is the output format we're looking to consume. * Unlike most other rich text editors, CKEditor 5 will likely support pasting from Word (and possibly Excel) in the future[2]. Our end users are likely to copy content from Word and Excel (after all, we're creating "Excel for apps"). Handling this well is notoriously difficult -- here's the CKEditor 4 implementation[3]. Where TinyMCE makes this a proprietary add-on[4], CKSource will likely make this part of the open source version of CKEditor 5[5]. * When CKEditor 5 matures, CKSource will offer commercial support. * We're interested in adding collaborative editing to our SaaS solution in the future, and CKSource's Letters project[6] demonstrates that CKEditor 5's architecture is up to the task. * What should the HTML output of a rich text editor look like? CKSource's "Editor Recommendations" project (licensed under a Creative Commons license) spells out this in detail[7]. * CKEditor 5 is licensed under permissive open source licenses (MPL and LGPL in addition to GPL). * CKEditor 5 has a responsive community and an active chat channel where the core developers hang out[8]. The downside to adopting CKEditor 5 at this early stage is that the project isn't fully mature yet. There's no out-of-the-box support for things like colored text and tables (though adding support for colored text through a plug-in is trivial, thanks to how the architecture works). Also, browser support is spotty. Internet Explorer is not supported in any capacity (Internet Explorer 11 may be supported in the future[9]). While Edge is formally supported[10], we found problems that were serious enough for us to disable the editor when that browser is run. (Our SaaS application falls back to plain text editing when rich text editing is not available on account of the user's browser.) Also, only Safari 11 (released on September 19, 2017) works with the default build of CKEditor 5 due to a WebKit bug[11]. Finally, only recent versions of Firefox can be used that support the "selectionchange" event (which means Firefox 52 and later versions; Firefox 52 was released on March 7, 2017). All in all, we're happy with our choice, but you may want to wait for the project to mature given the issues cited above. [1] https://github.com/ckeditor/ckeditor5/issues/488 https://github.com/ckeditor/ckeditor5/issues/488 [2] https://github.com/ckeditor/ckeditor5-design/issues/172 https://github.com/ckeditor/ckeditor5-design/issues/172 [3] https://github.com/ckeditor/ckeditor-dev/blob/major/plugins/pastefromword/filter/default.js https://github.com/ckeditor/ckeditor-dev/blob/major/plugins/... [4] https://go.tinymce.com/powerpaste/ https://go.tinymce.com/powerpaste/ [5] https://gitter.im/ckeditor/ckeditor5?at=59af4683c101bc4e3a94023c https://gitter.im/ckeditor/ckeditor5?at=59af4683c101bc4e3a94... [6] https://ckeditor.com/letters/ https://ckeditor.com/letters/ [7] http://ckeditor.github.io/editor-recommendations/ http://ckeditor.github.io/editor-recommendations/ [8] https://gitter.im/ckeditor/ckeditor5 https://gitter.im/ckeditor/ckeditor5 [9] https://github.com/ckeditor/ckeditor5/issues/330 https://github.com/ckeditor/ckeditor5/issues/330 [10] https://github.com/ckeditor/ckeditor5/issues/423 https://github.com/ckeditor/ckeditor5/issues/423 [11] https://bugs.webkit.org/show_bug.cgi?id=171041 https://bugs.webkit.org/show_bug.cgi?id=171041
unhammer 9y ago
That's great news for anyone writing editor plugins :-) I've worked a bit on plugins for TinyMCE, CKEditor 4 and Quill before, where the plugin had to change the content. The Quill editor (which has a separate data model similar to what the article describes) was a heck of a lot easier to work with than the others because of the data model[1], and the end result felt a lot more maintainable, even though Quill is newer and has much fewer Stackoverflow answers ;) [1] https://quilljs.com/docs/delta/ https://quilljs.com/docs/delta/
lucaspottersky 9y ago
I feel like all of these web "WYSIWYG editors" should be renamed to "WYSI _not_ WYG editor"... :(
- pjasiun 9y ago
  This is why this type of editors should be called "rich text editor" not WYSIWYG. Note that you will not find "WYSIWYG" in the article.
netzone 9y ago
This looks similar-ish to Substance[0] [0] http://substance.io/ http://substance.io/
nath_ 9y ago
Will this support BBCode or will it have to be some sort of plugin?

Interesting. That's always the way I thought it should be done, with a separation of display and structure. I used to work with a developer who maintained and actually made a decent chunk of change licensing out a very popular rich text editor developed before ContentEditable was even a twinkle in the browsers eyes. We used it pretty heavily within the company as well. Knowing first hand the horrible feats of iframe content string manipulation that had to be done to make an RTE work in Netscape and IE5.5, ContentEditable seemed like a DREAM. Ends up there's still a demo up for it, and it almost entirely still works! https://kevinroth.com/rte/demo.htm https://kevinroth.com/rte/demo.htm

dualogy 9y ago
Man, sites like this make me nostalgic =) https://kevinroth.com/projects/ https://kevinroth.com/projects/ gonna have to check out that ASP 3 stuff..
CitizenKane 9y ago
Oh man, I worked with Kevin a long time ago in my first web dev job. I remember this existing even at that point. Cool to see it here, haven't thought about these things in a long time.

atonse 9y ago

Looking at all these editors makes me feel good about having chosen mobiledoc 18 months ago for my ember app. I don't know if mobiledoc pioneered this approach of separating the data model but it was the first time I saw it and it felt right. Glad to see so many editors do this now.

jhchen 9y ago
I’m the author of Quill and I will attribute my decision to David Greenspan of Etherpad. Not sure if they are the first but it certainly predates all the examples I know of.
- phirschybar 9y ago
  I just discovered this. Very cool!
Reinmar 9y ago
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/ 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.
- atonse 9y ago
  Congrats to you and your team :) Developers (and users as a whole) only benefit from having more great editors to choose from.

dgreensp 9y ago

It still uses contenteditable, though, like Quill and ProseMirror, which also use a custom data model and ops. It sounds like CKEditor has caught up to have this kind of architecture too. Not to trivialize this accomplishment. All three are impressive feats of engineering and design.

wakeywakeywakey 9y ago
Can you point to where contenteditable is used? I was not able to see the attribute when inspecting the demo source.
- jameskilton 9y ago
  https://ckeditor5.github.io/ https://ckeditor5.github.io/, inspect the content editing div itself, it's there. One thing I've realized playing with a ton of different editors is that contenteditable gives you one very important feature that you can't fake yourself: access to the browser's spell check and corrections. It's possible that CKEditor ignores everything else about contenteditable, but turns it on just for red squigglies.
  - mook 9y ago
    Spellcheck and corrections can be faked, I think, if you decide to compile your own hunspell (or whatever). IME (i.e. entering text for languages that do not have a one-to-one mapping of key press to character), though, is a lot harder; you have no idea what languages the user has configured, and showing _everything_ in a list is impractical.
    - mwcampbell 9y ago
      Not only IMEs for various languages, but also alternative forms of input such as speech recognition.
    - steadicat 9y ago
      Few people seem to know about Composition Events: https://w3c.github.io/uievents/#events-compositionevents https://w3c.github.io/uievents/#events-compositionevents Using those, implementing IME should be relatively easy. The events tell you which partial characters to show, and which completed characters to insert.

zschuessler 9y ago

Looking great for a first release! The demo is smooth, well done. Seems like there's a good framework in place to catch up to the competition. I'd switch away from TinyMCE or Summernote if there was a component/widget system that worked well. Writing custom behavior for any HTML editor is painful, and none of them have a big use case in mind: custom layouts. SiteOrigin's Page Builder for WordPress is cool: https://wordpress.org/plugins/siteorigin-panels/ https://wordpress.org/plugins/siteorigin-panels/ I wanted something (Free or paid) like what's shown in the above video, that's independent of WordPress. Couldn't find a darn single one, if you can believe it. I'm stuck with Summernote + workarounds to get something similar for a Laravel project of mine.

deleted 9y ago
[deleted]
pbowyer 9y ago
> I wanted something (Free or paid) like what's shown in the above video, that's independent of WordPress. Couldn't find a darn single one, if you can believe it. I can, because I've been looking for one. I believe there's a market for well done components like this: * Drag and drop page component builder (think Leadpages, Unbounce, SiteOrigin Panels) * Drag and Drop email builder (a la MailChimp et al) There's no need for every SaaS and startup to build their own - better to have a component (or even a dedicated service to integrate) to provide these JS-heavy timesinks than waste time while validating the idea creating them.
- slig 9y ago
  > Drag and Drop email builder (a la MailChimp et al) Have you seen this? https://github.com/unroll-io/react-email-editor https://github.com/unroll-io/react-email-editor was released recently.
  - leesalminen 9y ago
    Wow, this is exactly why I read HN. I was Googling for exactly this yesterday. Thanks much!

bluetwo 9y ago

I'm a happy CKEditor 4 user, but let me know when this gets to 5.1.1. With so much rework, I just can't see myself rolling the dice and rolling this out right away! Congrats, though. Seems like an ambitious three year long project that you actually pulled off!

phirschybar 9y ago

Is the output just a giant blob of HTML? If so, I don't see what this does to solve what I see as the main problem of WYSIWYG editors... a terrible end-format for stored content. I got my hopes up when reading the intro that we would see a more structured output (not just the underlying in-browser data model). I would love to see a WYSIWYG output a JSON structure with markdown content. Not to minimize what appears to be a massive and successful effort! I just feel like HTML is a completely inflexible and rigid way to save content.

justinator 9y ago
The demo video at the bottom of the page shows that it can output to Markdown easily.
- Reinmar 9y ago
  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.html 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-text-data-4b3a507af552 https://medium.com/content-uneditable/a-standard-for-rich-te...
dotancohen 9y ago
> ... the main problem of WYSIWYG editors... a terrible end-format for stored content. In many cases having the editor store HTML internally is the best solution, especially if the output will eventually be HTML anyway. Think of a Wordpress post submission page, or a website comment page.

frik 9y ago

"Most of the editors out there are based on ContentEditable, including CKEditor 4 and its previous versions. But ContentEditable is bad and ugly, though. It’s implementation among browsers is not standardized and its behavior for end users is often out of control" Yes, please W3C, Google, Mozilla, MS, Apple do something! Improve ContentEditable or create a new better standard for it!

marijn 9y ago
People [1] are working on this, but as usual with standards processes, it's slow and there's constant pushback from browser implementors. [1]: https://www.w3.org/wiki/Editing_Taskforce https://www.w3.org/wiki/Editing_Taskforce
Reinmar 9y ago
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.

williamstein 9y ago

I tried to use the Letters demo on my iPad Pro 10.5 and it wouldn't even let me try. I can't remember hitting another website in months that flat out denied "mobile" access like that.

wiktor_walc 9y ago
I'm sorry for this, but please note that this was a conscious decision to show products at the current state. We wanted to give the voice to the community to help us prioritise the development as soon as it makes sense. If we showed everything to the public once its fully ready (having all the nice to have features in place, brilliant support for mobiles), you would have no chance to let us know, for example, how you would like those features to behave etc. How exactly do you see the mobile support and so on. We did not want to blindly copy CKEditor 4, adding just the new architecture to it.

tonyspiro 9y ago

Froala is still my WYSIWYG editor of choice https://www.froala.com/wysiwyg-editor https://www.froala.com/wysiwyg-editor

onurozkan 9y ago
Both froala and reactor are pretty expensive products imo. They are really good editors and i believe they both worth it, but i would prefer cheaper or opensource alternative.

smacktoward 9y ago

ContentEditable was supposed to bring us a world where things like CKEditor no longer needed to exist. What on Earth happened? HTML5 has pushed the web platform so far forward from where it was back then; how did this one little corner of it end up stagnating?

lstamour 9y ago
ContentEditable never really specified much of a cross-platform standard API. If we wanted to replace CKEditor and its ilk, we should have pushed for a standard spec on textareas with rich structured editing support for a variety of formats (Markdown, reStructuredText, HTML, etc.) But that would then require standardizing structured text formats and/or figuring out how to add extensible functions, what to do with copy and paste especially from third-party apps, how should drag and drop be handled, what about saving, auto-saving, how should you add styles to a drop-down list to let users pick their own fonts, font-sizes, etc. These are complicated things to get right, often site- and implementation-specific, and contenteditable allowed for direct text manipulation and editing (with spell check and native text cursor flickering) within HTML, which is good enough to build your own rich editing interfaces around. So, it would be going too far to say ContentEditable was supposed to put these RTEs out of business. In fact, I would argue that Markdown's popularity has done more to put RTEs out of business recently, and that block-based, template- or widget-integrated text editing is the future, and where these tools' APIs are headed.
onurozkan 9y ago
We were too busy with js framework hypes :(

braindead_in 9y ago

Is there any editor which mimics the look and feel of Google Docs or MSWord?

johndoe90 9y ago
AFAIK CKEditor has theming support and one of bundled themes is MSWord.
onurozkan 9y ago
might work for you. http://jejacks0n.github.io/mercury/ http://jejacks0n.github.io/mercury/ for complete wysiwyg editor list; https://github.com/cheeaun/mooeditable/wiki/Javascript-WYSIWYG-editors https://github.com/cheeaun/mooeditable/wiki/Javascript-WYSIW...
- edwinyzh 9y ago
  mercury sounds very good, too bad it seems to be abandoned.

sideproject 9y ago

Rather than using an all-inclusive editor like CKEditor, Froala or Redacted, I've been thinking a lot about a "block" based content creation like one that is available on https://www.notion.so https://www.notion.so http://madebymany.github.io/sir-trevor-js/example.html http://madebymany.github.io/sir-trevor-js/example.html https://www.froala.com/pages https://www.froala.com/pages (Looks like Froala also gives a block-based design in addition to their rick text editor) As we continue to insert and embed a variety of content types into these editors, I feel like this approach is more suitable. Any thoughts?

manigandham 9y ago
It's really all the same, HTML is already a component-based system but the parsing and tooling for it is poor when used through javascript. Maybe WebAssembly will change that but using a content-block approach is definitely a way to get around some of the complexity. Medium's editor uses a similar approach, probably the most common and there's Mobiledoc which is a standardized JSON format and editor framework: https://bustle.github.io/mobiledoc-kit/demo/ https://bustle.github.io/mobiledoc-kit/demo/ Side note, list of various editors: https://gist.github.com/manigandham/65543a0bc2bf7006a487 https://gist.github.com/manigandham/65543a0bc2bf7006a487
- jordanlev 9y ago
  I do a ton of work with CMS's, building sites for non-technical clients who manage their site without much knowledge of HTML, CSS, or any coding/encoding (even markdown would be a bit much for some of my users). The big win that you get with a block-based system (as opposed to 1 big chunk of HTML) is that it allows us to build out the content editing interface in a way that is very "guided" for the user... like, if there is a photo gallyer, we have a repeating list of slides and they have fields for a photo and a caption. Then on the front-end we can build our HTML+CSS markup around those specific fields. You can't do that easily with 1 big chunk of HTML.
  - manigandham 9y ago
    Right, that's what I mean about HTML tooling. It's a fine data format but DOM manipulation isn't very good compared to a JSON data structure with native integration into javascript and more universal parsing ability. The mobiledoc format is a good start at standardization.

polskibus 9y ago

Can anyone tell whether CKEditor 5 approach differ from draftjs? If so, what are the pros and cons of each?

onurozkan 9y ago
afaik, you cant use draftjs projects like slate, react-rte (both of them awesome) with another framework like vuejs or angular. and you need to store your content as json or you should write parser for each custom block you defined.
madhato 9y ago
Big con for draftjs is it doesn't support Android.
- polskibus 9y ago
  I didn't know that, I thought it did. What do you recommend as an alternative to draft that works well on mobile? Do you know if draftjs will fix this bug?

NicoJuicy 9y ago

I recently heard of CKEditor because of the dev log on tweakers.net ( a popular dutch news website).. They mentioned CKEditor, so they actively use it. Here's the link: https://tweakers.net/plan/1385/finetunen-van-de-lay-out-en-hands-on-development-iteratie-117.html https://tweakers.net/plan/1385/finetunen-van-de-lay-out-en-h... ( dutch)

jasonkester 9y ago

It's got to be tough spending a career working on ContentEditable. I don't know how these guys handle it. Not only do you get to spend all day every day wading through the impossible pile of bugs, contradictions, mutually exclusive implementations and downright wackiness in the thing itself (did it seriously just allow the selection to include the opening DIV tag of the contenteditable itself???), but you get to have the same conversation every day with developers who haven't ever used ContentEditable and therefore consider it to be trivial. "Why are you implementing the caret in javascript? Haven't you heard of ContentEditable?" "Why is your simple WYSIWYG editor component seven megabytes of javascript? Wouldn't it be better to just use ContentEditable and be done with it?" I only had to work with the technology for a few months. Years ago. And I'm still scarred today. Props to these guys for sticking it out!

Tade0 9y ago
Former member of the CKE team here. Three words: it was hell. The CKE people are some of the most hard working devs I've ever encountered in my life. I still find it funny how making little details like backspace/delete key behavior work is such a gargantuan task. And almost nobody gets it right.
- nicoburns 9y ago
  I actually applied to CKE as my first job as, having made my own WYSIWYG editor [0] as a side project while I was at school, it seemed like something I had experience of. Never heard back from them: sounds like I dodged a bullet then! [0] https://github.com/nicoburns/ghostedit https://github.com/nicoburns/ghostedit
  - Tade0 9y ago
    I guess it was probably because(to my knowledge) only recently they started hiring junior developers. Anyway it was a hard and thankless job, but during these almost two years I learned a lot about having an, um, work ethic and doing things to the best of my ability. Also my current job looks really easy in comparison.

Vinnl 9y ago

The new release looks really nice, congrats to the devs. Although I haven't looked into it too deeply, the new editing model made me think of Draft.js [1], which might be interesting to some people as well. [1] https://draftjs.org/ https://draftjs.org/

marijn 9y ago

The "end of contentEditable" spin in this is weird. CKEditor 5 uses contentEditable. And that's a good decision—getting bidirectional text, IME, touch selection, spell-check, and screen reader support right without contentEditable, while possible, would require you to reimplement a _lot_ of browser functionality, which would necessarily lead to a blowup of complexity and download size. So sure, the new CKEditor does more or less what Quill, Slate, ProseMirror, and most other modern WYSIWYG components do—it separates its data model from the editable DOM. That's good, but not new.

amelius 9y ago
I'm wondering, how does Google Docs do it? And how do they achieve having a reasonably compact size?
- marijn 9y ago
  They appear to have reimplemented most of these things, doing their own layout entirely etc. I wouldn't call google docs compact, but indeed, it's also not overly bloated, and it handles corner cases well. It'd be interesting to know more about its architecture.
igravious 9y ago
I can't find where in the codebase they employ contentEditable. Are you sure they still use it? Here is a GitHub search: https://github.com/ckeditor/ckeditor5/search?utf8=%E2%9C%93&q=contentEditable&type= https://github.com/ckeditor/ckeditor5/search?utf8=%E2%9C%93&... 3 Markdown documents, one JSON doc.
- marijn 9y ago
  Focus a demo editor [1] and inspect `document.activeElement` in the console. You'll get a parent div of the content whose `contentEditable` attribute is true. [1]: https://docs.ckeditor.com/ckeditor5/latest/examples/builds/classic-editor.html https://docs.ckeditor.com/ckeditor5/latest/examples/builds/c...

exikyut 9y ago

Nobody's asked this, so: I've been fascinated with operational transformation for some time, but I haven't found anything that breaks it down into understandable steps. I vaguely recall that last time I poked around I found an extremely high-level algebraic breakdown that made no sense, and only after a _lot_ of digging was I able to turn up an actual example implementation that wasn't 100% useless (because contextless) theory. I fear that understanding OT is a case of for example spending 6 months reading Etherpad.

manigandham 9y ago
Try this video: https://www.youtube.com/watch?v=pMMDVphop40 https://www.youtube.com/watch?v=pMMDVphop40 One of the best overviews covering CRDTs and OTs, especially in the context of collaborative editing.
pjasiun 9y ago
6 months is a very optimistic scenario ;) A guy responsible for OT in Google Wave wrote once that he spent 5 years on it and it still does not work well in all cases. After 3 years of struggling to get it right, we know what he meant. Anyway, I believe that you can find a good entry point to OT here: http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation http://www.codecommit.com/blog/java/understanding-and-applyi.... It gives a nice overview of the problem – in a human-readable language – but it’s only the beginning of the journey. The original OT implementation has been designed for linear documents – texts. It does not fit very well with tree structure – you don’t want elements (tags) to intersect after resolving collision. It also does not fit undo where the order matters. For sure, operational transformation is not a closed subject, which you can just learn. It is an open problem with many cases still unsolved. If you are looking for a good topic for a thesis, I would recommend it :)
- exikyut 9y ago
  > 6 months is a very optimistic scenario ;) Oh. > A guy responsible for OT in Google Wave wrote once that he spent 5 years on it and it still does not work well in all cases. After 3 years of struggling to get it right, we know what he meant. ...Wow, I see. (As an aside, I think it's really sad Wave's "cool" UI was never properly released.) > Anyway, I believe that you can find a good entry point to OT here: http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation http://www.codecommit.com/blog/java/understanding-and-applyi.... It gives a nice overview of the problem – in a human-readable language – but it’s only the beginning of the journey. I actually think this is one of the articles I found a while back. I agree that it's very thorough and in-depth, and, uh, I've managed to get slightly further into it before I started hitting PgDn repeatedly and my eyes glazed over than when I read this a few months ago! :) > The original OT implementation has been designed for linear documents – texts. It does not fit very well with tree structure – you don’t want elements (tags) to intersect after resolving collision. It also does not fit undo where the order matters. Ooooooooh yowch. > For sure, operational transformation is not a closed subject, which you can just learn. It is an open problem with many cases still unsolved. If you are looking for a good topic for a thesis, I would recommend it :) Hah! When I was exploring OT a few months ago I also explored alternatives such as realtime diff/match/patch into a model held in server memory. The simplest way to do this ultimately stores approximately documentSize*clientCount for every single document. That lets me keep an exact copy of every client state on the server, letting me tag updates with the hash of what the document should now look like. For small-scale projects the massive-but-not-concretely-exponential memory requirements of such an approach is somewhat out of control but not completely unmanageable: 1000 documents of 1MB each being edited by 20 clients each requires 20GB of RAM. (But my first guesstimate of sane limits - 10000 documents and 500 clients - would require 5.2TB though, haha.) Hmm. I just realized... some of the buffer architectures commonly used in text editors might be usable to implement server-side deduplication. Or... you could even probably just implement a copy-on-write scheme. Either would probably be an effective design win because (in the contemporary/common case) all clients editing a given document are generally seeing a 99.99%-accurate representation of that document relative to other users; if the network is good, there's only really a few characters' difference between users. OT feels like architectural overkill at the fundamental level, but I know that's just my overwhelmedness with the mental models required and the sense of "does it really have to be this hard?". I recognize that it really is that tricky, and kudos for keeping at it and then turning around and making the result open source! :D

bfu 9y ago

Font hinting went on a vacation on those pictures

PythonicAlpha 9y ago

What about Trix? Froala was already mentioned, I also heard about an editor namend Trix, that also claims not to use ContentEditable. http://trix-editor.org/ http://trix-editor.org/ Any experiences with that?

ivanhoe 9y ago
Actually they say: "Trix sidesteps these inconsistencies by treating contenteditable as an I/O device". They use it to capture the input, which they then process and pump it back into the contenteditable. So technically speaking they do use it, just in a weird way.

sandGorgon 9y ago

I wish there was an official react build for this. I had tried sometime back, but the integration with react fiber was a little tricky and kind of gave up.

chenglou 9y ago

I don't see many people talk about Apple's approach to text editing, on iCloud.com Pages. They use svg and it allows them to achieve some pretty fancy effects. Anyone experienced with this method?

madhato 9y ago
That is pretty neat. They use an invisible content editable field that moves to where the caret is placed. The content editable only contains the current word or selection. Text typed into the content editable is rendered into SVG elements. Unfortunately that doesn't allow a browser's spellcheck to work so they had to implement their own. iCloud Notes works in a similar way but it renders to canvas elements instead of SVG. Also doesn't provide spellcheck.

rkagerer 9y ago

Such nostalgia! I remember playing with this over a decade ago when it was still called FCKEditor. Kudos, Fred and team! (If we're doing show and tell, my old quick and dirty prototype for a structured FAQ editor still mostly-works under Firefox http://www.googlemappers.com/dev/prototypes/faq/template.htm http://www.googlemappers.com/dev/prototypes/faq/template.htm)

davidpolberger 9y ago

We have selected CKEditor 5 for our SaaS application for the following reasons: * We need to implement a custom user interface and CKEditor 5 makes this easy. Its modular nature enables us to build a custom "headless" bundle using Webpack. Keystroke handling is currently tied to the CKEditor 5 user interface, though, which is problematic as you don't want to reimplement what the Enter key does when editing, say, lists or block quotes. The team is actively looking into this issue, though, and it is possible to use a custom user interface while still benefiting from CKEditor's keystroke handling using a hack I documented here[1]. * The output format is (very clean) HTML. If we ever change our implementation to use another rich text editor, we don't want to write a server-side migrator moving user content from one editor format to another. Also, HTML is the output format we're looking to consume. * Unlike most other rich text editors, CKEditor 5 will likely support pasting from Word (and possibly Excel) in the future[2]. Our end users are likely to copy content from Word and Excel (after all, we're creating "Excel for apps"). Handling this well is notoriously difficult -- here's the CKEditor 4 implementation[3]. Where TinyMCE makes this a proprietary add-on[4], CKSource will likely make this part of the open source version of CKEditor 5[5]. * When CKEditor 5 matures, CKSource will offer commercial support. * We're interested in adding collaborative editing to our SaaS solution in the future, and CKSource's Letters project[6] demonstrates that CKEditor 5's architecture is up to the task. * What should the HTML output of a rich text editor look like? CKSource's "Editor Recommendations" project (licensed under a Creative Commons license) spells out this in detail[7]. * CKEditor 5 is licensed under permissive open source licenses (MPL and LGPL in addition to GPL). * CKEditor 5 has a responsive community and an active chat channel where the core developers hang out[8]. The downside to adopting CKEditor 5 at this early stage is that the project isn't fully mature yet. There's no out-of-the-box support for things like colored text and tables (though adding support for colored text through a plug-in is trivial, thanks to how the architecture works). Also, browser support is spotty. Internet Explorer is not supported in any capacity (Internet Explorer 11 may be supported in the future[9]). While Edge is formally supported[10], we found problems that were serious enough for us to disable the editor when that browser is run. (Our SaaS application falls back to plain text editing when rich text editing is not available on account of the user's browser.) Also, only Safari 11 (released on September 19, 2017) works with the default build of CKEditor 5 due to a WebKit bug[11]. Finally, only recent versions of Firefox can be used that support the "selectionchange" event (which means Firefox 52 and later versions; Firefox 52 was released on March 7, 2017). All in all, we're happy with our choice, but you may want to wait for the project to mature given the issues cited above. [1] https://github.com/ckeditor/ckeditor5/issues/488 https://github.com/ckeditor/ckeditor5/issues/488 [2] https://github.com/ckeditor/ckeditor5-design/issues/172 https://github.com/ckeditor/ckeditor5-design/issues/172 [3] https://github.com/ckeditor/ckeditor-dev/blob/major/plugins/pastefromword/filter/default.js https://github.com/ckeditor/ckeditor-dev/blob/major/plugins/... [4] https://go.tinymce.com/powerpaste/ https://go.tinymce.com/powerpaste/ [5] https://gitter.im/ckeditor/ckeditor5?at=59af4683c101bc4e3a94023c https://gitter.im/ckeditor/ckeditor5?at=59af4683c101bc4e3a94... [6] https://ckeditor.com/letters/ https://ckeditor.com/letters/ [7] http://ckeditor.github.io/editor-recommendations/ http://ckeditor.github.io/editor-recommendations/ [8] https://gitter.im/ckeditor/ckeditor5 https://gitter.im/ckeditor/ckeditor5 [9] https://github.com/ckeditor/ckeditor5/issues/330 https://github.com/ckeditor/ckeditor5/issues/330 [10] https://github.com/ckeditor/ckeditor5/issues/423 https://github.com/ckeditor/ckeditor5/issues/423 [11] https://bugs.webkit.org/show_bug.cgi?id=171041 https://bugs.webkit.org/show_bug.cgi?id=171041

unhammer 9y ago

That's great news for anyone writing editor plugins :-) I've worked a bit on plugins for TinyMCE, CKEditor 4 and Quill before, where the plugin had to change the content. The Quill editor (which has a separate data model similar to what the article describes) was a heck of a lot easier to work with than the others because of the data model[1], and the end result felt a lot more maintainable, even though Quill is newer and has much fewer Stackoverflow answers ;) [1] https://quilljs.com/docs/delta/ https://quilljs.com/docs/delta/

lucaspottersky 9y ago

I feel like all of these web "WYSIWYG editors" should be renamed to "WYSI _not_ WYG editor"... :(

pjasiun 9y ago
This is why this type of editors should be called "rich text editor" not WYSIWYG. Note that you will not find "WYSIWYG" in the article.

netzone 9y ago

This looks similar-ish to Substance[0] [0] http://substance.io/ http://substance.io/

nath_ 9y ago

Will this support BBCode or will it have to be some sort of plugin?