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

> > if it is enabled it can easily lead to issues if a user then adds executes execCommand to the beforeinput event handler.
> 
> I'd rather have a consistency that `beforeinput` event is fired whenever `input` event is fired since `execCommand` does fire `input` event.

Basically, I agree with that.

> Every inconsistency like this is an extra cognitive pressure every new Web developer has to endure, and we should avoid adding such a thing as much as possible.

From point of view of different position, there is consistency between setting `.value` and `execCommand()` if browsers don't dispatch `beforeinput` for every changes from JS.

We've already been struggling with mutation event listeners for avoiding security issues so that I don't want new path to nesting edit actions.

What Safari does for the case to call `execCommand` from `beforeinput` event listener?

> We can make `event.isTrusted` to `false` or add a new boolean to `InputEvent` to make it obvious if there is a use case in which `beforeinput` fired for `execCommand` needs to be disambiguated against ones fired for user initiated editing operations.

I feel it's odd. [`Event.isTrusted`](https://dom.spec.whatwg.org/#dom-event-istrusted) should be set to `true` if it's dispatched by browser and even if it's caused by JS 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-527325687