Closed zcorpan closed 1 year ago
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.
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:
@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 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.
cc @chrishtr @annevk
I can volunteer as editor for this spec.
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.).
I discussed this with colleagues and maintaining this makes a lot of sense to us. Two things:
Hope that helps!
@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.
@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?
@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)?
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.
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).
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:
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.
Sounds good.
- 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.
- 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:
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.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:
So when is exexCommand not harmful?
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.
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.
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.