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

> @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 <code>contentEditable</code>, 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

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

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