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!
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.
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!
Once again I'm sorry for the lack of reply. Back in I.2013 our team was much smaller and we were overloaded with post release stuff shortly after launching CKEditor 4.0.0. So lots of emails were left unattended :(
Tade0 (buongiorno!) was right that at that time we were not looking for junior developers, but ofc the lack of reply was a mistake on my side.
Yep, I'm working there ;) Please send us the details via contact form https://ckeditor.com/contact/ or feel free to PM me directly at ["w.walc", ["cksource", "com"].join(".")].join("@")
I'm curious, have you ever used TeXmacs? It is, in my non-expert oppinion, by far the best WYSIWYG editing experience (barring some minor implementation bugs). The visual bounding box cues, in particular, make formatting much easier.
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.
Having did a fair bit with ContentEditable ~13 years go it was downright crazy back then - biggest issue being the wildly different HTML produced by different browsers, which I did handle by server side processing. From what I recall it was nothing but a big bag of special cases.
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!
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.
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
We have in mind the "block-based editor" or "content builder" solution you're talking about. This could be relatively easily created having CKEditor as its base. This means that CKEditor may not be the ready to use way for it but it provides a good framework to develop such solution.
For example, its powerful widgets system [1], which can be used to handle "blocks", providing at the same time an excellent user experience.
At the same time, it would avoid issues that we see with the current solutions or prototypes available out there. For example, paragraphs would not be treated as separate blocks, like a video embed, but instead, they would be part of the content flow. This would allow for easy selection of multiple paragraphs. This would also avoid issues with large selection copy-and-paste.
What is needed here, is work. And this work much probably would go beyond the CKEditor scope, because it needs some level of integration with the application. It needs the development of such "blocks, and control of its behavior. All this on top of a dedicated UI solution, maybe in some senses similar to what we have with Letter [2].
There are hundreds of different use cases for editors. Our intent with CKEditor was designing a decent framework for others to build on top of it. It would be great to see the community getting together to bring such solutions to life. We're more than happy to help.
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/
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.
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.
I've been wondering if this wouldn't be good for something like MarkDown editors that show the output as you type side-by-side, because you would be able to limit compilation to the block being edited (in this case, to maintain document structure the blocks would have to be be defined by headers).
Although I also would expect that dedicated tools do this already for efficiency purposes.
The reason I'm thinking about this is because I once saw a product in development at an e-learning company where they showed me a new product where (among other things) they wanted the students to write their stuff in MarkDown, in a naive "re-render the whole thing on every keypress" way. This... did not really scale at all.
You could probably get away with re-rendering at the actual paragraph level, provided you do a bit of minimal bookkeeping to track which input paragraph corresponds to which output paragraph—which, if you want to make it so that the input and output windows scroll alongside each other, you need to do anyway.
On a note that's tangentially related to this but more directly related to the top-level post, ProseMirror has a demo which involves a markdown-to-WYSIWYG editor where both sides are editable: http://prosemirror.net/examples/markdown/
Wagtail has a similar sort of thing, inspired by Sir Trevor I think, called StreamField; it still has to have a RichTextBlock type to support inline-level formatting (bold, italic, links, etc.) Currently it's either CKEditor or TinyMCE (I forget which) but they're replacing it with something implemented using Draft.js and serialised as JSON, which isn't far off what ProseMirror or this new CKE version do as far as I can tell.
The block-based content is an idea that has been around for a long time and is embodied in several CMS's. Concrete5 has them baked into its core, ExpressionEngine and Craft CMS have the "Matrix" fields, Wagtail has "Streamfields" (as another commenter mentioned), most of the hosted CMS's now have it (Weebly, Squarespace, etc), some of the flat-file CMS's and static site generators have it (Kirby and Lektor off the top of my head), and even Wordpress has had it for a while via the amazing "Advanced Custom Fields" and "Flexible Content Fields" plugins. (And wordpress is about to get a lot more block-y with their new "Gutenberg" editing interface, although it still spits out one big chunk of HTML which means you don't get the front-end markup advantages that you do with a true block-based system).
As a developer, there are 2 advantages I've found to the block-based approach:
1) The editing interface can be custom-tailored to the content and the non-technical users who are editing the site via a GUI interface can be more "guided" through the data. E.g. a photo gallery can have repeating list of slides and each slide has separate image + caption fields. This is hard to do with a single WYSIWYG editor (Worpdress uses "shortcodes", for example, but those are a terrible UI for most non-technical users... the whole point of a GUI is to not have to use code)
2) The front-end HTML+CSS markup can more easily be customized around the content fields. Using the image gallery as an example again... since each photo + caption of a slide is a discreet content field, I can insert that into any photo gallery markup I want. If the input data is itself HTML (as it would be from a WYSIWYG editor), I don't have that ability (unless I parse the HTML I guess, but that is terribly brittle and making a ton of assumptions about the generated HTML that will probably change depending on WYSIWYG widget version, where the content was pasted in from, etc).
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.
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.
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).
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.
There is a route you can go that doesn’t use contenteditable, except as a small box at the cursor position to handle IME; it’s what Google Docs does. At my most recent job (stealth start-up) we built an editor like this, painting our own selection and everything. It makes certain things easy or possible — custom text wrapping, tab stops, custom handling of cursor and selection with regard to embeds. It doesn’t get you very far on mobile web, though.
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.
Using those, implementing IME should be relatively easy. The events tell you which partial characters to show, and which completed characters to insert.
Unfortunately, it's not that easy. Composition events are typically controlled by the IME software, which is not part of the browser proper, and tends to be a lot less serious about conforming to standards. The result is that the data in those events often simply doesn't correspond to the actual DOM changes that they caused. On Android, you can't even rely on the fact that compositionstart fires when a composition is started—with some virtual keyboards (which act as IME providers) you routinely get compositionupdate or compositionend before a start event.
Listening to these events and using DOM diffing can get you a more or less accurate idea of what happened. But 'relatively easy' does not apply.
I have yet to find a free contenteditable-based WYSIWYG editor that works properly with the Korean IME in recent versions of iOS. Duplicate characters everywhere. Even the Enter key sometimes works and sometimes doesn't, depending on what character is immediately before the line break. Froala is better, thanks to a Korean guy who helped develop a fix for them despite the fact that it's not even FOSS.
It is true that working with IME is hard, even though it is kind of supported by operating system and browser.
As much as it is doable for standalone editing, it is a nightmare for collaborative editing, where content changes all the time - not only at the place where you type. Each content change may cause composition (IME) to break. That's how the browser works.
This is one of the reasons why "real-time collaborative editing" solutions often implement "block limiting" -- one block/paragraph can be edited only by one user at the same time.
Enabling IME will be one of the toughest goals for CKE5's collaborative editing solution - Letters: https://ckeditor.com/letters/
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.
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.
> 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.
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.
The idea behind storing and loading the data is, in short, this: HTML is the most popular format and it is the default when it comes to publishing web content. Most people want HTML data.
However, it is understood that in the modern web era, there is a need for more. In CKE5 there is a "data processor" unit. The data processor is responsible for taking DOM (generated from editor's data model) and converting it to the output you want. The default processor is HTML processor, but you could hook there any processor that can convert DOM structure to anything you want. You can use already existing libraries or write your own if you need something really custom.
To sum up, the road from editor's model to the output data is this:
custom model -> view (DOM-like structure) -> DOM -> Data processor -> stringified data
> ... 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.
I agree HTML in its entirity is not a great way to store data, but a SUBSET of HTML is often pretty efficient.
Storing a paragraph where words might be bold or italic — a string of HTML’s pretty great for that, compared to some convoluted JSON thing, and can pretty easily be converted to other formats if needed.
Even a list of paragraphs with mixed occasional lists etc. HTML is still pretty friendly at that point.
I think where HTML strings outlive their usefulness is when you start mixing in <div> <iframe> <script>, nested sections. The string starts becoming unpredictable at that point and you have to worry about side effects.
But for use cases where you want a small whitelisted set of tags, I think HTML is great.
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.
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?
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.
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.
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.
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.
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.
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.
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 :)
> 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.)
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
The fact that that article needs 10 plus pages to describe one of the simplest use cases belies the unfortunate underlying truth: OT (and realtime co-editing) is intractably difficult for all but the most constrained data models. Which is a pity because it is undeniably cool, and why we built Convergence (https://convergencelabs.com) -- general-purpose realtime collaboration.
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.
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?
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.
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!
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.
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.
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 ;)
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.
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.
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.
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?
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.
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.
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.
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.
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.
"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!
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.
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!