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

> I meant that whether `beforeinput` event is dispatched or not when web apps modifies editable contents with API. I meant that if `beforeinput` event is fired only while calling some API, it's inconsistent between API.

I still don't understand what you're trying to say. It seems more inconsistent for `beforeinput` to not fire in cases where `input` event would otherwise fire.

> Indeed, except stack-overflow risk.

That's not a security risk.

> > > I feel it's odd. `Event.isTrusted` should be set to true if it's dispatched by browser and even if it's caused by JS API.
> > 
> > 
> > This is why I suggested an alternative which is to add a new boolean on `InputEvent` itself. However, is this even a use case that comes up? What are concrete use scenarios in which author scripts need to behave differently when `beforeinput` event is triggered by execCommand?
> 
> I have no idea for handling `beforeinput` caused by `execCommand`. That means that web apps may want to distinguish whether each `beforeinput` is fired by `execCommand` or not.

But **why**? What are scenarios in which one has to distinguish the two?

If someone is writing a library which needs to react to whenever an editing operation gets triggered in a `contenteditable` region (e.g. in order to update corresponding data model), then it needs to listen to such an event regardless of whether it happened due to direct user inputs or `execCommand`. There is no need to distinguish the two.

> If so, web apps need to set a wide scope flag to check it in event listeners. Therefore, I think that it's better not to dispatch`beforeinput` event at `execCommand`.

Again, why? What are scenarios in which author scripts have to rect differently in those two cases?

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