Isn't execCommand obsolete?

[mkmaker]

https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand

Mozilla docs says:

This feature is obsolete. Although it may still work in some browsers, its use is discouraged since it could be removed at any time. Try to avoid using it.

[jaredreich]

😢

[mkmaker]

What does this suppose to mean? 🤔

[jaredreich]

It means that's unfortunate, since this library makes ** heavy ** usage of execCommand and there's no existing alternative. Do you have any ideas?

[mkmaker]

Nope :( and I am using it in my upcoming project. Might have to remove it ☹️

[jaredreich]

FYI, almost all other WYSIWYG editors will also be using execCommand

[danleyb2]

So sad.
I was using LitElement to create a wrapper around a WYSIWYG editor.
Pell was the only editor that worked with shadow DOM because of it's use of execCommand

[VaelVictus]

I'd be surprised if this was removed any time soon. Are you still working on Pell, @jaredreich ?

[jaredreich]

@danleyb2 I agree with VaelVictus, I don't think execCommand will be going anywhere. There's no alternatives available for contenteditable and it's widely used in almost all wysiwyg editors.

[jaredreich]

@VaelVictus I have been actually, but unfortunately it's been going extremely slow due to work and life stuff... you know. I'd like to get ramped up asap and solve all the issues and release v2.

[ShahrukhAhmed89]

Looking at the codebase of Squire, TinyMCE, Medium Editor & Trix and all use execCommand at some capacity. Others that don't are just too bulky for my taste.

[VaelVictus]

@jaredreich Are you still interested in a v2? There are some nice pull requests you might want to review for v1.

[buncis]

trix use its own document model

but Ithink what makes pell is the lightest is because its using execCommand

@jaredreich you want open disscussions for the repo? because I think some issues better to be as a question instead an issue

edit:
damn I forgot 2020 is 2 years ago lmao

[jaredreich]

Moved to discussion.

[johanneswilm]

@jaredreich None of the editors that are of production quality are using execCommand. We have added that notification there many years ago. I am very sorry that you have spent time creating an editor on top of execCommand. it is precisely what we wanted to avoid people wasting their time on.

There have been alternative technologies for many years that editors have been built on. See for example the beforeinput events. Or check out CKEditor 5 and ProseMirror and editors based on them.

[jaredreich]

I withdrew my angry response as I thought you were another random GitHub troll. Thanks for providing context in your follow-up comment.

[jaredreich]

Anyways, I created this project in a day or two for a personal project, and decided to clean it up and open source it for others to use and learn from, which they have. So I don't feel sorry about it at all :)

[johanneswilm]

@jaredreich Ok, I understand. And I'm glad it was just that. Around 10-15 years there were lots of projects were someone tried out creating prototype in just a day using execCommand. That kind of worked and then they spent multiple years trying to create a working product on top of that only to discover that it ultimately is impossible to do without shipping something with lots of weird behavior.

[johanneswilm]

@jaredreich I have been the editor of the execCommand spec for the past decade or so. See https://w3c.github.io/editing/docs/execCommand/ . I am also the editor of the input events spec that has been implemented in all the browsers for some years now. I have just given up being the editor of the execCommand spec and came across this editor by accident. At the very beginning of the execCommand spec there is a big warning that we placed there to avoid having people waste their time on trying to create editors based on it. I wasted several years on that myself more than a decade ago. I am so sorry that we apparently weren't clear enough. It's just not possible to create an editor that behaves the same everywhere, works across browser versions, with working change history, etc. with execCommand.

@ShahrukhAhmed89 I looked at the source code of Squire today.

ExecCommand is used for just one thing in Squire: It turns of some extra table controls on Firefox to make it behave like other browsers. This used to be built into all editors a few years ago. Firefox has since changed so that these commands no longer are necessary. Some editors, like Squire, have not yet removed these commands. I have filed an issue with Squire to explain.

[ShahrukhAhmed89]

Thanks. I have been using quill for a couple of years. It's a bit bulky but users seem to like it.

[jaredreich]

Thanks for the background info. So what's the main recommendation here, use contentEditable /designMode+beforeinput to attempt to recreat pell without execCommand?

[johanneswilm]

@jaredreich The thing that seems to be working across browsers and browser versions is contenteditable/designmode + having your own document model so that with every user action, you go through steps like these:

1. Identify what change the user tried to make.
2. Apply that change to the document in your own model.
3. Render your document model to HTML.
4. Diff the actual innerHTML of the contenteditable element with the HTML from step 3.
5. Apply the diff to the contenteditable element.

This turns out to be the most robust way that has been found to create a working JS editor with plain contenteditable. However, it also means a lot more code. And there are some cases, namely IME input (Chinese, Japanese, Korean, Android, etc.), that will have to be handled in a special way as the input will cancel out if one starts applying diffs in the middle of an IME-session.

So to make this easier, we came up with the beforeinput event in the Input events spec. It allows you to do point 1 more easily as it tells you exactly what the user wanted to do. And by canceling it, the browser won't actually apply any DOM changes itself, so you don't have to do diff and apply in steps 4/5 and can just apply the change directly (5).

Unfortunately, beforeinput on contenteditable is insufficient to handle IME, so one still needs to do some complex diffing there. So what we are currently working on is a whole new system called EditContext API that will also take care of that.

Doing all this is still more code than just building on top of execCommand. But luckily, there are some libraries that do a lot of this for you and that allows one to create an editor with very custom behavior. So timewise, in most cases, it shouldn't take that much longer. While I understand that it would be nice to just use execCommand, the principal two problems with that are:

1. Browser makers just cannot prioritize editing in the same way these editing JavaScript libraries do. Bug reports will be open for more than a decade and still not be fixed. And there is no way for you to fork it and make it work the way you want to.
2. ExecCommand doesn't really allow for customization of editing commands. It turns out that just about every editor eventually wants to have some behavior be different, and once one changes just a little bit of the DOM using JavaScript, the document change history will be broken.

I hope that explains it. It's always possible that things change in the future, but as far as I am aware, this is the current state of things.