Re: [w3c/uievents] Event order between "compositionend" and "input" (#202)

> But it doesn't seem (to me) like it's very common to need to distinguish between input events that are inside or outside composition. The vast majority of devs won't care.

Most web apps don't do text editing at all, and those 99% won't care, I agree. But what we need to look at are the 1% (or less) of devs working on editing apps. Without such editing apps, there is no content on the web so even if the percentage is low, it does matter for the web overall.

Those web apps doing text editing need to be concerned with the difference between composing and non-composing as they are prohibited from changing the DOM around the composition while it takes place. So as long as that is clearly communicated in some way, I think everything is fine.

> If Web apps are waiting for `isComposing` === false and then taking some action that results in the DOM being updated and the composition canceled then they might arrive at a state where the string being composed remains, and not the final string that should have been committed.

If `isComposing` is set to `false`, while it really should be `true` and it does cause IMEs to be canceled half-way, then the web apps will stop checking that attribute and will be looking for some other indication of whether the composition has finished.

That is not really ideal as we are then moving away from the idea that you can build an editor by listening to `beforeinput` events and go back to the kind of patchwork that editors need to go through today.

-- 
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/uievents/issues/202#issuecomment-437677096