Misrepresentation of editor landscape

[johanneswilm]

Hey,
thanks for this great editor. One note though: In your readme, it says:

Most WYSIWYG editors are wrappers around HTML’s contenteditable and execCommand APIs [...]

As the person who has been responsible for the execCommand spec over the past decade (recently stopped), I feel this is a misrepresentation of the editor landscape. Editors generally stopped using execCommand 8-15 years ago. Most production ready editors now do the exact same thing you describe below and they have been doing so for a long time. There seems to be some differences in how much they rely on the beforeinput event, but those are minor details. This may have been true-ish in 2015, but it does not seem to be the case anymore.

Why does it matter?

It has been hard for us to get the message out there that editors should not be built on top of execCommand. The production level editors all know that, but time and again there are individuals who start yet another execCommand-based editor. The waste a year or two of their lives on it, only to realize that it is not technically possible to create a consistent editor that way. Statements like the one in your readme unfortunately do not help as they give an incorrect picture of the editing landscape and give false hope to those trying to create editors that way.

[afcapel]

@johanneswilm thanks for your work on the execCommand spec as well. I remember reading the spec some time ago and thinking it was impressive that someone had reverse engineered and documented all those browser quirks.

I'm afraid the README was written long time ago and it's a bit outdated. Do the changes in #1093 look good to you?

[johanneswilm]

@afcapel Yes, thank you. That addresses the issue fully.