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

> What do you mean? Do you mean that the UI Events spec should be changed?

yes. It doesn't make sense compositionend (and/or compositionupdate) is fired on different element if the composition is committed after the element blurred. compositionstart should be fired on the focused element, but other composition events should be fired on the element which has the composition.

>>> That is what Chrome/Safari do, while for Firefox the Event.target is the element that was focused BEFORE the composition started.
>> In these days, modern IMEs queries content information before compositionstart. Therefore, moving focus at compositionstart is too late for native IMEs.
>  What are modern IMEs for you and what are native IMEs?

Most Japanese IMEs are using surrounding text for prioritize the items in its candidate list at converting a word. For example, "saku" can be converted to "咲く" (bloom) or "割く" (tear). Then, the previous word is important for guessing what the user expected. If the previous word is "花が" (A flower)、"咲く" must be better. If the previous word is "布を" (cloth), "割く" must be better. So, this modern IME may query previous content of the insertion point. There is another scenario, user may commit composition with wrong candidate item. Then, user can use "Kakutei-Undo" (undo the previous commit). When user type Ctrl + Backspace, IME sets selection which covers the last committed string and restart the composition. Therefore, for Japanese IMEs, the preparation before composition start is very important.

Similarly, as far as I know, Thai language's IME queries surrounding text and replace it with new composition string if it's necessary since Thai characters are combined one or more characters.

Moving focus at compositionstart kills such features completely. So, such web application isn't useful.

> I tried this on Chrome on Mac OS X with one of the Mac OS X built-in IMEs, and the Chrome example still works, which means that it's no problem to move the focus somewhere else during compositionstart for Chrome on Mac OS X. Also Safari is able to move the focus during compositionstart.

I think that some features which I mentioned above must not work in such cases.

> And what is "our editor's bug"?

I meant that it is a bug of Firefox's editor.

> <input> and <textarea> do not matter much to us right now. In the Editing taskforce we are trying to fix editing in the browser, and having this work correctly is a key component.

contenteditable case is very complicated. If a document has two or more contenteditable elements, focus may be switched from one of them to another one. In such case, how to commit composition string at blur is difficult issue since all contenteditable elements share an editor instance in a document.

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