
CKEditor 5: New approach to rich text editing on the web - davidpolberger
https://ckeditor.com/blog/CKEditor-5-A-new-era-for-rich-text-editing/
======
jasonkester
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
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
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)

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

~~~
eximius
Oh, are you currently employed there? I found a minor-ish XSS vector allowed
by CKEditor 4 if there is a place I should submit an issue...

~~~
wiktor_walc
Yep, I'm working there ;) Please send us the details via contact form
[https://ckeditor.com/contact/](https://ckeditor.com/contact/) or feel free to
PM me directly at ["w.walc", ["cksource", "com"].join(".")].join("@")

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

------
donatj
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
Man, sites like this make me nostalgic =)
[https://kevinroth.com/projects/](https://kevinroth.com/projects/) gonna have
to check out that ASP 3 stuff..

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

------
dgreensp
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
Can you point to where contenteditable is used? I was not able to see the
attribute when inspecting the demo source.

~~~
jameskilton
[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
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.

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

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

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

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

~~~
edwinyzh
Very cool! But you might want to make it clear that it's not fully open
sourced - the github repo is just a wrapper your hosted js library.

~~~
slig
Ouch, I did not realise that until now. Thanks for pointing it out.

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

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

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

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

~~~
igravious
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&...](https://github.com/ckeditor/ckeditor5/search?utf8=%E2%9C%93&q=contentEditable&type=)

3 Markdown documents, one JSON doc.

~~~
marijn
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/c...](https://docs.ckeditor.com/ckeditor5/latest/examples/builds/classic-
editor.html)

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

~~~
pjasiun
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-
applyi...](http://www.codecommit.com/blog/java/understanding-and-applying-
operational-transformation). 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
> _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-
> applyi...](http://www.codecommit.com/blog/java/understanding-and-applying-
> operational-transformation). 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

------
Vinnl
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/)

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

------
bluetwo
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!

------
atonse
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
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
I just discovered this. Very cool!

------
unhammer
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/)

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

~~~
onurozkan
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-
WYSIW...](https://github.com/cheeaun/mooeditable/wiki/Javascript-WYSIWYG-
editors)

~~~
edwinyzh
mercury sounds very good, too bad it seems to be abandoned.

------
rkagerer
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))

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

------
NicoJuicy
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-h...](https://tweakers.net/plan/1385/finetunen-van-de-lay-out-en-hands-on-
development-iteratie-117.html) ( dutch)

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

~~~
madhato
Big con for draftjs is it doesn't support Android.

~~~
polskibus
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?

------
davidpolberger
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/...](https://github.com/ckeditor/ckeditor-
dev/blob/major/plugins/pastefromword/filter/default.js)

[4] [https://go.tinymce.com/powerpaste/](https://go.tinymce.com/powerpaste/)

[5]
[https://gitter.im/ckeditor/ckeditor5?at=59af4683c101bc4e3a94...](https://gitter.im/ckeditor/ckeditor5?at=59af4683c101bc4e3a94023c)

[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)

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

------
williamstein
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
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
Froala is still my WYSIWYG editor of choice [https://www.froala.com/wysiwyg-
editor](https://www.froala.com/wysiwyg-editor)

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

------
netzone
This looks similar-ish to Substance[0]

[0] [http://substance.io/](http://substance.io/)

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

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

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

------
bfu
Font hinting went on a vacation on those pictures

------
frik
"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!

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

