Re: [uievents] specify how compositionend works if the caret has been moved to a different element (#5)

I still believe that a set of composition event (compositionstart -> compositionupdate * n -> compositionend) should be guaranteed that they are fired on a same element which is focused at compositionstart.

First, compositionstart event should be computed the its target as focused (editable) element.

Next, *if* compositionstart event handler moves focus and the browser starts composition on the new focused element, compositionend should be fired on the old focused element first, then, compositionstart and following composition events should be fired on the new focused element.

Another possible cause is, if compositionupdate or input event handler moves focus and the browser continues the composing process in the new focused element, the old composition string should become empty string (or restore selected string which was removed by composition?), then, compositionupdate (if necessary) and compositionend should be fired on the old focused element and compositionstart and compositionupdate (if necessary) should be fired on the new focused element.

This composition event process can support the stateful web apps with a pair of composiitonstart and compositionend. And even in new focused editor, a set of composition events are guaranteed.

In conclusion, I believe that UIEvents need to change the composition event target as:

compositionstart: focused element
compositionupdate: an element which compositionstart event fired on.
compositionend: an element which compositionstart event fired on.

And the above behavior should be explained in UIEvents (Although, we've not had agreements if composition should be moved to new focused element, but for existing browsers, this behavior should be defined).

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/5#issuecomment-151682987