ckeditor5-design

mooth UI and great UX. Right now, we're in a state where: * after spending several months on it, text editing is well supported on iOS and Android (including spellcheck and stuff) – we don't get any bug reports recently about that part, * the default UI is not working great on smaller devices. The sad part is – we don't have any bigger plans to address the latter. We have some smaller ideas for making the current UI more responsive, but there will still be fundamental issues that you will face when using it: * The conflict between the native UI (the balloons/panels with paste/copy/cut/bold/italic) and the custom editor UI. I've been bringing that to the W3C's attention since 2015 and nothing happened since then (most recent topics: [2], [3]). Right now, I don't have the funds anymore to lobby for this (neither have anyone else, apparently), so those topics seem to be completely stale. * Inability to display your UI and implement functions like scrolling to the caret in a reliable way on WebKit due to its broken viewport mechanics [4]. I even talked about this with one of the Apple devs responsible for the current behavior and he agreed that there may be a problem (a good first step :D), but I got literally zero feedback after the last year's TPAC in Lyon when I presented this issue. * And more... IMO, it's due to those issues that we haven't seen a single editor (implementing more than some really basic functions) with a good and stable UX on both iOS and Android. Every solution I saw was flawed in one way or another. I'm not saying that it's completely impossible to build such a solution, but rather that, taken all the obstacles and moderate demand (desktop is still the main platform for rich-text editing), the ROI seems too low for anyone to invest enough in it. Anyway, feel free to contact me (e.g. via https://twitter.com/reinmarpl) if you'd like to discuss this more. [1] https://github.com/ckeditor/ckeditor5-design/issues/149 [2] https://github.com/w3c/editing/issues/176 [3] https://github.com/w3c/editing/issues/182 (my presentation from last year's TPAC) [4] https://gist.github.com/Reinmar/91c70d2882523f47da7c49805042...

lso, 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 [2] https://github.com/ckeditor/ckeditor5-design/issues/172 [3] https://github.com/ckeditor/ckeditor-dev/blob/major/plugins/... [4] https://go.tinymce.com/powerpaste/ [5] https://gitter.im/ckeditor/ckeditor5?at=59af4683c101bc4e3a94... [6] https://ckeditor.com/letters/ [7] http://ckeditor.github.io/editor-recommendations/ [8] https://gitter.im/ckeditor/ckeditor5 [9] https://github.com/ckeditor/ckeditor5/issues/330 [10] https://github.com/ckeditor/ckeditor5/issues/423 [11] https://bugs.webkit.org/show_bug.cgi?id=171041