Re: [w3c/editing] [charter] execCommand spec should be in scope (Issue #432)

> My research so far leads me to conclude that not many libraries or sites use `execCommand` very much (but still a substantial enough number to be worried about web compat), which is another reason to be conservative about accepting normative changes.

That is because it is **dangerous** to use `execCommand` for the formatting in a richtext editor that is used to **save** the text. You get different markup depending on which browser was used, which is most likely not what you want. It's what you would see in the early 2000s with early CMSes like Joomla & co where the output HTML is a bit of a mess after multiple users with various combinations of operating systems and browsers have been editing a particular text. This will also be true even if you manage to specify execCommand down to every detail, as long as there is no way for JavaScript-based customization.

That's why we have seen multiple generations of editors in the past twenty years. For example:

* The earliest models tried to call execCommand. They would quickly find out that it was broken and that any type of manual dom manipulation by JavaScript to achieve custom behavior would break the document history.
* Then there were editors that contained a large number of browser-specific fixes for specific situations. They would need to write their own history module (or just skip that part) and not call execCommand that much. But they would let the browser native behavior on user input in contenteditable go through and then subsequently apply their situation-browser-specific fix. Some got relatively good at this, but they then also became very heavy as they would need to contain a large number of browser specific fixes. 
* The heavy weight of some of the better editors of the first generation caused a large number of "super light-weight" editors to be launched. The idea was always "we can just create a really thin editor on top of execCommand and replace that old heavy first generation editor". A MVP editor created in an afternoon worked great for marketing purposes - to write a few words as part of an on-stage presentation. But they would fail miserably if anyone tried to actually write some text and have the text be editable in any browser and/or OS.
* At some point of time in the last decade we started seeing editors that would no longer contain a large number of browser specific patches, but instead use their own system where the editor would contain its own model of the text, which could be transformed into a virtual DOM which then in-turn could be diffed toward the real contenteditable element after each user-provoked mutation. These editors started working much more robust than previous models. This technique is still largely in place in the better editors. 
* In recent years, through the work of this group, we have identified some of the remaining usecases for execCommand and some of the pain points the modern editors have had. On of the most common uses for execCommand was, for example, to turn off the native table controls in Firefox off so that Firefox would have like other browsers. And some clipboard actions couldn't be done in any other way. Most of that should be gone by now. The "Input Events" spec that we have been working on here has given more useful events to editor developers, even though Chromium managed to remove some of the advantages in the last second when it came to IME.
* The next generation of editors should be able to handle even those IME situations by means of "EditContext" which has been developed in this WG over the last few years.

So when is exexCommand not harmful?

* If the editor is not saving the output markup. An example that came up was a webapp that allows users to paste text, the editor then transforms the text in various ways and requires the user to copy the result out. The cleanup of the markup will need to happen in another editor (wherever the user pastes the text).
* If the text does not have to move between browsers and operating systems. A company could for example lock all of its users down to use the same version of the same in-house browser and force everyone to use the same OS. That way all the markup will have the same structure, no matter what browser the users are using.

Given that execCommand is shipping everywhere, it's a good idea to document and standardize it to the extent possible without removing resources from the implementation and fixing of more modern editing technologies. But we would be doing the JavaScript editor community a disservice if we communicated to them that execCommand is a technology they should use to create text editors. It is not. There are better ways to do it that have been shipping for years and are working well that go beyond the capabilities of execCommand, and there are more things coming in the not-so-distant future that will be a better fit.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/432#issuecomment-1599664991
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/432/1599664991@github.com>