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

> As far as I know, some developers want to use only simple `execCommand` for making modification undo-able with browser built-in undo stack. 

The empirical data we have collected so far shows something else. 

It's impossible to do so as long as the editor supports at least one operation that requires JavaScript dom manipulation. Even if you create an editor that only does those things that are covered by execCommand, it will not work because only using browser built-in operations means that it will produce different HTML in different browsers. I made an extensive survey about practices, and we arrived at this result [1]. 

The execCommand calls that are in use would be `copy` and probably still `enableObjectResizing` and `enableInlineTableEditing` because Firefox only recently removed the need to execute these two. It's also possible that there are intranet solutions which require all users to use the same browser that use `execCommand` somewhat more extensively.

Do you have data showing something else? In that case it would be interesting to look at.

> Anyway, not point of this issue.

Actually it is. If there is no interest from the JavaScript side in `execCommand` - why are we (again) wasting all this time on it? I can understand from the persepctive of a browser developer that this seems like something that should be fixed, just as newbie web developers will likely try to write their first 5 line text editor with it. It's once you have to write an editor that is not just for demoing purposes, that either has to run in multiple browsers or do at least one operation not supported by the browser, or that you have to get around at least one bug in the browsers that you notice that this isn't an option.

> I don't think that `beforeinput` even is a good solution for that purpose because it cannot catch DOM tree modification by DOM API. Isn't mutation observer designed for such purpose? I think that events defined by UI Events are useful only for listening user actions.

I think about ten years ago it was probably normal to have say 10 or 20 small independent JavaScript programs run on a page that didn't interact much with oneanother and where it would be possible for one program to modify the DOM and for another to only notice later. This is not common practice today. The different libraries used on a webpage are all connected by means of a common main program and also generally bundled into a common bundle. The editing library will get a DOM element that it will have "full  control" over and so there should not be these arbitrary changes to the DOM coming from unknown sources.

Because we don't have beforeinput events level 2 implemented everywhere and so not everything is covered by it, the common practice in JavaScript editors indeed seems to be to use mutation observers to listen for changes within a certain range, but then not to use the information that comes with the event and instead just diff the dom. It's used in combination with a timeout so that multiple mutations that directly follow oneanother do not trigger a large amount of diffs.


[1] https://github.com/w3c/editing/issues/150

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