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

> 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`.

I guess this would be like level 1 of the spec. Would not that be weird in webkit though, as they have implemented level 2 which means that all of the beforeinput events can be cancelled? Is the `beforeinput` that comes with `execCommand` in webkit currently cancelable? If it is, I propose we just don't specify what it is. That way you can do what seems to make most sense in Firefox. I don't have a strong opinion though.

> 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`.

I think such a prefix would break the usecase described by @scottfr above. Also, given that `beforeinput` has not been present on Firefox so far, I think those editors that rely on it will likely additionally rely on some alternative methods anyway and know that they will update the app once Firefox has it. Could you describe a case in which an app would break because of this?



Sorry, I seem to have forgotten that this was an import

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