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

Today Masayuki and I discussed whether or not `beforeinput` should also set `isComposing` to false on the last event before updating the DOM. I'll summarize what I recall and Masayuki can correct me where I'm wrong.

Argument for making `isComposing` true:

* I think Masayuki was originally concerned that setting it to `false` would lead to bugs in Web apps. For example, while in a Japanese IME the final composition string is typically equal to the committed string, in Chinese IMEs it can differ (e.g. the string being composed might be all alphabetic and at the moment it is committed, it is converted to Chinese characters).

  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.

  (I'm a bit vague about this concern but hopefully Masayuki can clarify this point.)

Argument for making `isComposing` false:

* `beforeinput` and `input` are a conceptual set, so if `input` has `isComposing === false` then conceptually one would expect the corresponding `beforeinput` event to also have `isComposing === false`.

* Despite the concern mentioned above, given that the `beforeinput` events with `inputType === 'insertFromComposition'` are cancelable, there's probably no extra harm having apps trigger other actions at this point--at least from the UA's point of view, they need to be able to safely handle canceling at this point anyway.

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