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.

Great!

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

Ok, yeah I think that is something for us to think about. The reason that we have what kind of looks like a universal API for richtext editors. And it's working when in a five minute test and likely also for longer when you just sticking to a very small subset of what can be done with execCommand. But we haven't really defined the limits of where that stops working. In your case you only use `paste` which is probably is the safest way of adding richtext content to an editor because it already needs to be able to filter that. Emulating keystrokes from a keyboard is likely also relatively safe. However, even in your case, the `inputType` the editor receives is `insertFromPaste` whereas it really should be `insertReplacementText`.  It likely won't make much difference in most usecases, but there is always a chance that it does in some (for example if there is spell fixer in the editor as well, it should probably know that it shouldn't revert the fix your spell fixer just did).

And it doesn't work perfectly. You allow users to insert formatted text with specific colors and fonts. If the receiving editor doesn't allow those, it is stripped out. It's good that it is being stripped out, but it may be slightly confusing to users that they could specify in the first place. The other thing is that you allow users to specify tabs in the middle of the content that is being inserted. If the receiving editor doesn't allow tabs, that will instead result in the tab moving the caret to the next input field on the page and then pasting the remaining content there. And in some editors the shortcut defined in your app is triggered in the middle of a word, in others you need to type a space before the shortcut. I would think those issues are small enough to where the users are ok with them, but it will probably get annoying if users try to combine a handful of browser plugins and each of them breaks in certain situations. Therefore, long term, I think it would be preferably if there is a more clearly defined API for plugins to communicate with richtext editors.

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

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

I also agree that having consistency between beforeinput and input event would be preferable. What I want to avoid is that execCommand, and especially the lesser used parts "contaminate' the input events spec. The idea should be that if you want to create a JS editor from scratch, you "just" need to write an editor that handles all the inputTypes and then you are done. For that it's not helpful if we add new input types that cannot be triggered on any browser through native ui/shortcuts and we only add them because they are available in execCommand. I am thinking of things like "decreaseFontSize" or "insertImage". 

Maybe a solution is to cover those execCommands that don't have a corresponding `inputType` by using just an empty string as inputType as I believe is what execCommand already does for the input event. That is not an option according to the input events spec, but then again `execCommand` itself is not following any approved W3C spec, and so I don't see why we cannot just add this empty string as an additional `inputType` value in the `execCommand` draft that is then only used with `execCommand`.



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