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

> Every inconsistency like this is an extra cognitive pressure every new Web developer has to endure

It would be, if `execCommand` would be useful for web developers. The thing is - it's not. When you start writing a JavaScript editor, you may waste a week or so on trying to do it with `execCommand` until you find out that it's not actually possible to create anything production-quality with it and you start from scratch. That's why it's so important that we have the disclaimer there telling everyone to stay far away from it.

There also seems to be some interest in `execCommand` from some browser developers. I don't entirely understand the reason for that, and that reason may maybe have something to do why they want it to behave one way or the other? Either way, given that this is a technology not really in use and not really production ready despite having been shipped for more than a decade, I think we should contain it to the one spec draft with that big disclaimer, because otherwise it really gets confusing for web developers if they read about something they can do with `execCommand` one place without the disclaimer and only once they find the `execCommand` spec do they get to understand that they shouldn't actually use `execCommand`.

I haven't seen a real usecase for generating beforeinput events apart from `execCommand` in JavaScript either, except maybe to provide an event in some case where the browser isn't emitting it due to a bug. And then that should probably be fixed in the browser instead. Unless we find such a usecase, I don't think we should add anything about an untrusted version of the event behaving differently to the Input Events spec.

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