Re: [w3c/editing] Should execCommand dispatch beforeinput or not? (#200)

johanneswilm left a comment (w3c/editing#200)

Hey @GaurangTandon ,
since our discussion last time, I have done some experimenting with creating a grammar + spellchecking extension . I am not sure I understand what you need this for exactly. It seems to be possible to make just about any JS editor work with a custom extension, including Google Docs and Microsoft Word online, but one has to put quite a lot of effort into making it work with editors that are not contenteditable-based.  Even for contenteditable-based ones, one really needs to have custom code for a lot of sites.

The best fix, as far as I can tell, would be if the JS editors could agree on a common API for outside tools to hook into their editor. 

This is the sequence that seems to be the one that has the greatest change of working right now.

**For replacement/insertion:**

1. Try native API for this particular editor if we have it in our library of supported editors. If found, use it and stop.
2. Change selection if needed to be at the insertion point or cover the content to be replaced.
3. Try using beforeInput "insertReplacementText". If DOM changes, stop.
4. Try dispatching ClipboardEvent "paste". If DOM changes, stop.
5. Try execCommand "insertText/insertHTML" (which depends on whether or not it contains richtext).

**For deletion:**

1. Try native API for this particular editor if we have it in our library of supported editors. If found, use it and stop.
2. Change selection if needed to cover the content to be deleted.
3. Try dispatching keydown with key 8/46. If DOM changes, stop.
4. Try using beforeInput "deleteContentBackward". If DOM changes, stop.
5. Try execCommand "delete".

Note that for the beforeInput events, one needs to attach a custom getTargetRanges() function as there isn't any way to initialize the event itself with target ranges (a shortcoming of the spec).

```js
Object.defineProperty(event, "getTargetRanges", { value: () => [staticRange] });
```
Some editors use target ranges, others use the current selection when handling beforeInput. So set both to cover both cases.

There is no checking for whether or not is `isTrusted` in the editors I have found. But if there ever was - why wouldn't we respect that?

`execCommand` is in both cases a last resort. I think that makes a lot of sense. What would be really great is if we could get 1 (native api access) a lot easier. Google Docs and Microsoft Word online are some of the most difficult to make work, and if any code is changed, a previously working extension is likely to fail. However, with today's LLMs, it's always possible to find some way of making it work, so instead of making it more difficult, I would encourage the two to simply provide a standardized API. That will ensure the best possible user experience for those two editors and is likely to set a standard that will be adapted also by other editors (even if minor changes are needed to make it work with editors that don't occupy the entire site). I'd think that the same system would also be usable by dictation systems and iother custom software/hardware people want to connect to their favorite word processors.




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

Message ID: <w3c/editing/issues/200/5952931096@github.com>