[charter] execCommand spec should be in scope

[zcorpan]

Mozilla would like the execCommand spec to be in scope for the next Charter since it's required for web compat and is normatively referenced from HTML.

[johanneswilm]

Hey @zcorpan , the description of in scope and out of scope can be found in points 1.2 and 1.3: https://www.w3.org/2021/06/web-editing-wg-charter.html . As far as I can tell, the execCommand spec falls into the current scope.

Could you specify what you want to change in the in scope list? Or do you mean that you propose to make the execCommand spec a deliverable?

The issue thus far has been that (other than Mozilla?) no browser vendor wants to commit to implement the spec even if completed and that prevents the specification from advancing. This is due to several legacy apps that rely on the browsers behaving the way they do + it would take an extreme amount of resources to make browsers behave the exact same way. It's also the reason multiple other specs have been launched over the past decade, such as the Input Events spec or the EditContext spec, which both aim at making execCommand obsolete. JavaScript editors have largely stopped using execCommand many years ago.

If you can find a second browser vendor willing to commit to implement the spec and you can find someone willing to take over maintainership of the document and work a lot on it over the next few years, I would be in favor of putting it on the list of deliverables. If you cannot find such support, I don't see how we can commit to delivering it.

[zcorpan]

A normative deliverable, yes.

It can't be removed from browser engines today, so it should be specified normatively.

Here's evidence of work (not just from Mozilla) on trying to make improvements in this area last year:

• https://github.com/web-platform-tests/interop-2022-editing/
• https://github.com/w3c/editing/pull/407

[johanneswilm]

@zcorpan OK, and is someone from Mozilla willing to step forward as the maintainer and do you have a promise from a second browser engine to implement the execCommand spec? The reason I am asking is that other browser engines previously made it very clear that they would not make changes to their browsers based on what that a execCommand spec says, but that they may make changes if it can be shown that multiple other browser engines handle some case differently than they do. That's why we have had discussions about specific issues on Github or the mailing list over the last few years and some of those discussions have ended up with a change to the execCommand spec document.

As for evidence of work: If I recall correctly @masayuki-nakano / Mozilla proposed last year to work on a few things related to contenteditable that would also impact execCommand as part of the interop effort. This was accepted by other participants on the condition that what was going to be tested would be strictly limited to a few specific cases.

[zcorpan]

@zcorpan OK, and is someone from Mozilla willing to step forward as the maintainer

I'll check.

and do you have a promise from a second browser engine to implement the execCommand spec?

In this case all browsers already implement the API, and the question is how much interest is there in ironing out interop issues with it (which has inherent web compat risk and opportunity cost). It's tricky, certainly, but it doesn't follow that there shouldn't exist a normative spec.

The reason I am asking is that other browser engines previously made it very clear that they would not make changes to their browsers based on what that a execCommand spec says, but that they may make changes if it can be shown that multiple other browser engines handle some case differently than they do.

IMO the latter means that there is some interest, but I'll let other browser vendors speak for themselves.

That's why we have had discussions about specific issues on Github or the mailing list over the last few years and some of those discussions have ended up with a change to the execCommand spec document.

That's great.

[zcorpan]

cc @chrishtr @annevk

[zcorpan]

I can volunteer as editor for this spec.

[johanneswilm]

It's tricky, certainly, but it doesn't follow that there shouldn't exist a normative spec.

Right, and that's why the document exists in the form it has over the past decade with small modifications being done, but a clear note that the spec is likely not ever going to advance.

If we add it to deliverables, that is saying that we promise/hope that the document will advance in the W3C system over the period of the charter. Until now we have had no such ambitions because of the clear indications made by browser makers other than Mozilla. Additionally, Mozilla did not participate much in the Editing Taskforce/Working Group historically, so there was probably little expectation that a Herculean effort of implementing a finished spec would take place in Firefox.

But I notice there has been some more participation in the past year, so if only you can recruit a second browser maker to promise to implement an execCommand spec once it's reasonably complete, then I see nothing in the way of adding it to deliverables.

Note though that JavaScript editors work using other techniques than execCommand as of 2023. Even if execCommand were implemented without bugs in the exact same way in every browser engine, execCommand would need to get a new feature to allow extendability/customization for it to become of interest to most JavaScript editors. So I would ask you to make sure that any work on execCommand does not affect implementation/standardization work on other editing techniques that--at least for now--are of higher value to JavaScript editors (such as Input Events, EditContext, etc.).

[annevk]

I discussed this with colleagues and maintaining this makes a lot of sense to us. Two things:

1. The specification needs to be web compatible for it to be useful. Any changes to existing behavior of implementations need very good justification. Probably a higher bar than we employ elsewhere.
2. The specification needs to allow implementations to follow platform-specific conventions where applicable.

Hope that helps!

[johanneswilm]

@annevk Are you talking on behalf of Apple? That sounds like a different line of argument than what they have used previously, but if there is a commitment there, then we would have multiple browser engines!

I wonder, could a way to get implementations in more than one browser engine be to limit the spec to only document existing behavior (in the other browser engines)? If other browser engines aren't required to make any changes, then maybe that will make it possible to get a promise to implement the spec from them.

At any rate, execCommand is already taking a disproportionately large amount of time in the working group given its limitations and current usage with the spec text in its current state. I don't think it will get worse if it turns into a deliverable. In fact, the situation could improve if @zcorpan can put some time into maintaining and improving the text, checking where engines differ, etc. . So I think this is a good idea, at least to try out.

If we cannot promise what state the spec will advance to at what time, etc. then maybe it is a solution to add it to the items we may possibly deliver rather than the ones we set concrete dates and goals for. That way we won't over-promise.

[hober]

@annevk Are you talking on behalf of Apple?

Strictly speaking, only the Board of Directors and C-level executives speak on behalf of Apple, so no, he's not, and neither am I for that matter. :) That said, Anne discussed this with colleagues and shared the conclusions they came to. Absent new information, I'd expect those conclusions to be pretty stable.

but if there is a commitment there

A commitment to what?

[johanneswilm]

@annevk Are you talking on behalf of Apple?

Strictly speaking, only the Board of Directors and C-level executives speak on behalf of Apple, so no, he's not, and neither am I for that matter. :) That said, Anne discussed this with colleagues and shared the conclusions they came to. Absent new information, I'd expect those conclusions to be pretty stable.

@hober :) Yeah ok that's fine. I just wondered if this was Apple's position or that of Anne personally.

but if there is a commitment there

A commitment to what?

Previously, the messaging we received from the decision makers at Webkit, Blink and Edge was that they did not see it as being viable to try to fix execCommand/contentEditable. That was the backdrop for setting up this working group (initially as a task force) with a stated goal of creating new primitives for editing:

Editing on the Web, currently done through hacks sitting on top of contentEditable, is generally acknowledged by all practitioners as a nightmare. The goal of this task force is to split the work that is required into small, manageable chunks that can be developed as primitives useful on their own, and used together to create editing systems. [1]

We did take on the execCommand document back in around 2014, but the 3 browser makers made it clear that they would not change anything in their engines based on something such a document would say. Reasons for that were, among other things, various legacy applications each browser had to support, that it would take a lot of resources, and a realization among browser developers that execCommand would not be usable for most JavaScript editors unless a feature to allow customization of behavior through JavaScript was added.

So I am asking whether this has now changed and whether Apple would actually be willing to change code in its implementation in order to become compliant with an execCommand spec once Simon has improved it? In order for us to go through the W3C process, we will eventually need two implementations. And we probably shouldn't promise that we will deliver this spec if it's not actually achievable.

I understand you cannot commit to implementing a spec that does not fully exist yet, but at least it would be good if there was some intention to eventually do it. If it cannot be said with certainty whether or not the spec will actually hit REC, maybe we can list it under the second category of deliverables for which we don't make promises as to when it will be finished (as I mentioned above)?

[1] https://github.com/w3c/editing/blob/9bcb96cac6d451d5cb5f8e197b3e5f36bed3806e/tf-charter.html#L29C2-L37

[annevk]

I'm not sure who was at that meeting, but I don't think that's an accurate summary of how browsers at large feel about these APIs. Not then and not now. (I recall discussing this at the time inside Mozilla and there definitely wasn't agreement.)

I don't think W3C Process calls for commitments around charters and that is not something we generally comment on anyway. We are interested and supportive of this effort and I think that ought to suffice.

[johanneswilm]

I'm not sure who was at that meeting, but I don't think that's an accurate summary of how browsers at large feel about these APIs. Not then and not now. (I recall discussing this at the time inside Mozilla and there definitely wasn't agreement.)

Mozilla did not participate at that time, if I recall correctly. This was mainly Edge/Safari/Chrome and JavaScript developers. Were any of you at any of those Editing Taskforce meetings back then?

I am only trying to regurgitate the arguments given by other browser people in the past and I am concerned about us finally getting to a place where JavaScript editors can work, even with IMEs.

We may recall things differently, and that is OK. The important part is that there is consensus moving forward. I take it then that Apple's position is now that you are willing to implement a more fully developed execCommand spec and that Mozilla has the same position. And this has been discussed with those people who have been representing Apple in the taskforce over the past decade.

I don't know whether it is a hard requirement of a charter in the W3C system to state what one wants to do with the various specs, but at least ours has had two sections of specs: A) those that we promise to work through the W3C release system and B) those that might try to take through the system. Would you not agree that this would belong to category B? Unless the plan is to write the spec in a merely descriptive manner ("Safari does A, Chrome does B, Firefox does C"), there will be some challenges to make browsers behave the same (and thereby follow a specific spec).

If you propose to put it into section 3.1 of the charter, the specs for which we do give an expected completion date, then I'd want to know what time you expect it to be completed by, as well as which ones are going to be the two implementations, etc. and I think we will need to take this proposal up at the next call (in July).

[zcorpan]

I didn't attend Editing TF meetings back in the day.

I generally have little confidence in the timelines in W3C WG charters when specs are supposed to be done. As long as this spec is on the Rec track I would be satisfied.

Unless the plan is to write the spec in a merely descriptive manner ("Safari does A, Chrome does B, Firefox does C"), there will be some challenges to make browsers behave the same (and thereby follow a specific spec).

I envision a rough process like this:

1. Write the spec for any common ground where we already have interop, and verify with tests. Leave other parts as UA-defined, with tentative tests that demonstrate lack of interop.
2. Discuss if we can align on the UA-defined bits. If so, specify the behavior we want and fix browsers accordingly.
3. Repeat step 2 until either no UA-defined bits are left or we've reached diminishing returns.

[johanneswilm]

I generally have little confidence in the timelines in W3C WG charters when specs are supposed to be done. As long as this spec is on the Rec track I would be satisfied.

Ok, so that should be possible by having the spec listed in 3.2 without a specific timeline. I don't know how common it is to not stick to the proposed timelines, but I will do my best to make us stick to the timelines that are now in the draft of the 2023 charter as I think they are reasonable. I would be afraid that it would cause a lot of stress to put some arbitrary date on the execCommand spec as it's much more of an unknown and there have been a lot of browser people in the past saying it's so complex that it is just impossible to ever fully complete. And if it turns out that you are able to deliver a spec that goes through to REC before the end of this charter (2025), then - congratulations, that's just great!

Your proposed process sounds fine to me. And it also sounds very similar to what was attempted by @ayg with the initial text and what we since at times have been doing with a few individual issues. We can break the document out into its own repository if you prefer that, or it can continue to live where it currently is. That I would say is up to you. You can, of course, take some of the issues you run into up at the monthly Editing Working Group calls, but if it turns out there are too many and we don't get to discuss the more current editing specs that are used or will be used by JavaScript editors of the future, I think it might be a better idea to have special calls set up just to discuss execCommand/contenteditable. But those are details that we can discuss then.

[zcorpan]

Sounds good.

[chrishtr]

1. The specification needs to be web compatible for it to be useful. Any changes to existing behavior of implementations need very good justification. Probably a higher bar than we employ elsewhere.
2. The specification needs to allow implementations to follow platform-specific conventions where applicable.

I think these two points Anne mentioned make sense from a Chrome/Chromium perspective as well. I'd also like to note that:

• In practice item 1 will tend to result in choosing existing Blink/WebKit behavior if it's shared by those implementations.
• 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.

[johanneswilm]

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.

[zcorpan]

I agree execCommand() is legacy and the spec can be clear about that. The point here is not to change direction for how to write editors.

We (Mozilla) need to fix bugs with execCommand() for web compat reasons and consider what its behavior should be for e.g. contenteditable=plaintext-only (#419). My hypothesis for specs for legacy features is that they're an investment that pays off in terms of less interop issues and therefore less web compat issues.