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

We do not send typing to a server for processing, it's all handled locally. As a Chrome extension that needs read/write access to pages to function, user privacy and trust is very important. Also as a slight tangent, beyond the huge privacy issues, determining what snippet to insert on remote server would be much too costly from a latency perspective. Our (not always achieved) goal is to consistently complete insertion of a snippet within 50ms of the corresponding shortcut being typed by the user. Network requests would wreak havoc with that.

We haven't done testing in a collaborative context, but I think it would depend on the editor. Google Docs directs all editing keystrokes to an invisible iframe, so I assume it would work there even if other people are editing the same doc. I am not sure about other editors.

Back to the spec:

You are correct, additional input types aren't needed. It's just about emulating existing functionality as you say. If `paste` and `input` are bundled together but `beforeinput` is left out, we can't do that 100% accurately for now.

Going beyond the event ordering issue. I agree with one of the commenters above commented that:

> I'd rather have a consistency that beforeinput event is fired whenever input event is fired since execCommand does fire input event.

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