Should DOM be modified before or after compositionupdate? edge/IE do one thing, chrome/saf/firefox do another?

[garykac]

From @gked on January 13, 2016 1:53

Copied from original issue: w3c/editing#109

[masayuki-nakano]

We've already discussed about this.

At that time, compositionupdate should be cancellable and if it's cancelled, DOM shouldn't be modified for JS-IME. However, now, compositionupdate isn't cancellable. So, this reason does not make sense.

However, I think that there is input event which is implemented by all browsers and handling it allows web developers to handle any input. Therefore, firing compositionupdate before modifying DOM is better at least for now (beforeinput hasn't been implemented yet).

[garykac]

During the F2F, we agreed on the following order:

beforeinput
compositionupdate
-update DOM now-
input

Current browser behavior is:
IE/Edge fire compositionupdate after the DOM has been modified
Moz/Saf/Chrome fire it before the DOM has been modified.
So this requires that Edge updates its behavior so that all the browsers can have the same behavior/

[chong-z]

I know there was a resolution, but can we swap 'compositionupdate' and 'beforeinput' so the event order becomes:

*'compositionupdate'
*'beforeinput'`
-update DOM now-
'input'`

Reasoning

1. Previously we want to fire 'beforeinput' before 'compositionupdate' because IE/Edge has a different behavior, but IIRC @gked mentioned that it was a bug and will be fixed. (@gked can you help confirm?)
2. If IE/Edge could update the behavior then it makes more sense to fire 'beforeinput' immediately before DOM update as required by spec:

   A user agent MUST dispatch this event when the DOM is about to be updated.

[garykac]

I've begun working on a formal algorithm for these events and have the current draft in:

https://docs.google.com/document/d/1LJQvjEmWZGzVgZnofpvdkxMj1hEnLniD72XD4DLJWx4/edit?usp=sharing

I've used the compositionupdate -> beforeinput -> input ordering, and added a reference to this issue.