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

@scottfr I see. Yes this seems to work surprisingly well in several editors. It seems to break if the selection is changed while you type. So in a collaborative editor this would likely break seemingly at random, is that correct? And I assume you do all the processing client side so that you don't accidentally send people's emails/credit card numbers, etc. over the net and break GDPR and similar laws, right?


> Note that we do need to use `execCommand` rather than dispatching all the `paste`, `beforeinput` and `input` events ourselves as many editors just let these events pass through to be handled by the native browser functionality. Since our dispatched events in this case would not have the `trusted` bit set, the browser would not execute a paste based on them breaking many editors. The execCommand events do have the `trusted` bit set.

That makes sense. So maybe something about beforeinput should be added to the execCommand spec. You really only need this in order to emulate already existing native functionality with execCommand, so there should be no need to add more input types for those execCommand that don't have a browser native equivalent.

If we want to make it possible to create editors entirely without execCommand, we should likely also add a way of triggering a paste on an element in some other way - for example the clipboard api.


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

Received on Tuesday, 7 January 2020 10:05:10 UTC