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

> But I wonder, this means that extensions may implement browser feature with `execCommand` and web apps may want to cancel only some specific commands, so, it might be worthwhile to add `inputType` values for some commands.

As long as there isn't consensus on the answer to this question, it means that we do not have agreement on the point of using the empty string in these cases and the inputType that we write in the spec for those cases should then therefore be `undefined`, I believe. 

> And also, should be defined as the `beforeinput` events caused by `execCommand` within web apps should be one of the following options:
* always cancelable?
* same as `inputType` definition? (if so, how about for empty `inputType` cases?)
* always non-cancelable?

The usecase we found here and that we are trying to cover is to emulate already existing native browser behavior using `execCommand`. For that reason I would argue that it needs to behave as close as possible to the native browser behavior that it is trying to emulate (also in terms of being cancelable). In the case of an execCommand that does not have a native browser counterpart (so that the inputType is undefined) that is not something we have a usecase for currently, so I don't have an opinion.

Notice that this is not a perfect solution but just a temporary crutch to allow the insertion of content using execCommand paste which should be close enough to the desired results for many external grammar and spell checkers, auto text entering mechanisms, etc. . But the `inputType` will in most of these cases be semantically wrong so we continue to need a more permanent solution to be developed some time in the future. 

-- 
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-584224961