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

@kojiishi 

> What use cases do you have in your mind?

At a low level basically what you had proposed to do inside the browser with IME using the Shadow DOM to do IME input without changing the DOM. Only that @ojanvafai was strongly against that idea, so we found a solution whereby it should instead be possible to do things that way in JS code only [1].

At a higher level, the idea of having IME character commits come in "atomic commits" into the DOM. This would be helpful for among other things:
* Collaborative editing environments
* Creating a clientside undo history

> From the normal use cases, Chrome/Safari behavior is considered as a bug

What do you mean by "From the normal use cases"?

The part about the Chrome/Safari behavior that I cannot see anything about in the spec is that it pastes the created characters into the editing host where the caret is placed when the compositionend event is triggered. The rest of it is according to spec, as far as I can tell.

Firefox, on the other hand, does not follow the spec in several ways, AFAICT. First of all, it should not trigger the event twice. Secondly, the spec reads "Event.target: focused element processing the composition". That is what Chrome/Safari do, while for Firefox the Event.target is the element that was focused BEFORE the composition started. Unless JS moves the caret somewhere else, there will be no difference between where the caret was before composition started and during composition started, which is likely why they didn't think of this case when they wrote the code.

> Is it happening only when set from JS?

I am not sure what you mean. How would you set the caret anywhere else when compositionstart is triggered without using JS?

> Consider re-conversion, that turns existing text into composition.

This is something you only do in Android and that is not used anywhere else, right?

>  If the composition is inserted into DOM, and if the selection was moved, the original text must be restored. In that case, moving composition text into new caret is undesirable.

I don't think I understand what you are trying to say here.

In general, I don't think that this re-conversion should be a problem for the JS solution [1] possibly with some minor modifications. Could you outline what the process is exactly for re-conversion, or do you have a link?

[1] http://jsbin.com/pacisugiwu/1/edit?html,js,output 



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