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

> > 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 here surely means we should choose the latter (i.e. devs > spec writers).

I phrased that poorly. My concern is not for the spec writer (who only has to write it once), but for anyone who has to *read* the spec. A more complex spec is more complex for anyone who has to read it or any follow-on documentation (like MDN) that are based on the spec.

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

But needing to make this distinction in FF code isn't a good reason to expose this to the web platform.

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

These are compelling examples. Thanks for taking the time to write them up. These are good cases for motivating this change.

Would it be sufficient to phrase this as something like:
"During composition, the `isComposing` attribute should be `true` for all `input` events except for the final one that updates the DOM."

AUIU, if the user cancels composition, the final `input` would be a delete to remove the previous 
candidate. I think this is fine. I can't think of any other cases that might be problematic.

Does the final `beforeinput` event need to have `isComposing` set in the same manner? My instinct is "yes, it should", but I'm open to arguments why is doesn't need to be.


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