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

Thanks for following up on this!

> The tradeoff we're making is between:
> * Making the spec's description more complex: "isComposing is set when composing, EXCEPT when..." (ugh)
> * Making things slightly harder for devs who need to ignore input events during composition (since they have to add an event handler for compositionend).

That [priority of constituencies](https://www.w3.org/TR/html-design-principles/#priority-of-constituencies) here surely means we should choose the latter (i.e. devs > spec writers).

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

I disagree. @masayuki-nakano has already indicated that it is common to make this distinction in Firefox source. In my work on Web apps too, I frequently need to make this distinction. Some common examples include:

* If you are triggering a search as the user types, you don't normally want to do that search until the string has been committed since, in the case of Japanese, you'll be searching on the hiragana instead of the kanji so it will likely be wasted work and distracting to the user.
* If you're doing validation on data as it is typed, it's quite common that the uncommitted string will be invalid while the committed string will be valid and you don't want to annoy the user with "data invalid" UI while they're still composing. (As a concrete example, consider an app that checks an input station name is valid. While the string is uncommitted it will likely be incomplete or in hiragana but once committed it will typically be valid.)
* If you're doing auto-save based on user input, it would likely be wasted work to save before the string is committed.

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