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

>     * Add the `beforeinput` event to the `execCommand` spec draft. It's the closest thing we have to a real spec of `execCommand` so that's where that should live.

I agree.

>     * Add an empty string as an `inputType` for `execCommand`s that cannot be mapped to an existing `inputType` from the `Input Events` spec. Specify this in the `execCommand` draft spec.

If `inputType` value is empty string, I think that the `beforeinput` event should **not** be cancelable since it does not make to sense unknown events. Note that Firefox will dispatch non-cancelable `beforeinput` event for undefined edit operation with empty `inputType`.

>     * On the question on whether or not to add a `beforeinput` event only to `execCommand` if they come from a browser plugin or not, I do not have a strong opinion, but it would seem that for consistency it would be simpler to just add it every time.

Well, I still don't agree with that `execCommand` should cause `beforeinput` event (if the caller is web apps). However, if Chromium developers agree with that, Mozilla will follow that. But once browsers start to dispatch `beforeinput` for `execCommand`, there should be an API to distinguish whether coming `beforeinput` event is caused by `execCommand` or appending prefix or postfix to existing `inputType` values might be better. E.g., "execCommand-insertText". Then, I think that it won't break existing web apps which check `inputType` value of `beforeinput`.

(FYI: first implementation of `beforeinput` event on Firefox was landed yesterday into Nightly channel, you can test it with turning `dom.input_events.beforeinput.enabled` to `true` in `about:confing`.)


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