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

>     * **In case of browser plugins/extensions**: We agree that execCommand should cause a beforeinput event and that this beforeinput event should use the regular inputTypes in case there are is one corresponding to the command and otherwise an empty string. This should be added to the `execCommand` spec by means of a PR1.

I agree. 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.

>     * **In case of `execCommand` triggered within a webapp:** We are OK with also triggering a `beforeinput` event for `execCommand` commands being executed within a regular web page so this will be added to PR1.
> 
>     * **In case of `execCommand` triggered within a webapp:** We cannot at this stage agree on how or whether to mark the beforeinput event in some way: by means of the `isTrusted` attribute, by means of a separate attribute, by means of a prefix to the `inputType` or by nothing at all. So we will not add anything about this in the spec at this stage, but we will open a new github issue specifically about this issue.

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?

>     * We would like something about not allowing nested `execCommand` as is currently practiced by Chrome to the `execCommand` spec and we'll add it by means of a PR2.

Yeah, sounds reasonable and make it browser users safer.

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