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

@kojiishi Sorry, I didn't see your answer until now.

> IIUC, model 3 is a future thing, so let's focus on model 1/2.

Well, models 1 and 2 is kind of what JS editor developers are trying currently. The lack of support for IMEs in editors that are not primarily made for IME is probably exactly because of the problems they give. The idea here was to show why 1/2 are problematic, and why we have spent the past few years lobbying the browser makers and the last year creating a specification which will allow for model 3 and similar.

> 1. Browsers without Shadow DOM support. This may go zero in years though.

Well, for 1, there is the possibility to add a an area near where they are typing where the characters go during composition. That's the second polyfill. I know, you will say that is bad UI, but it's working and it's up to the browser makers to implement ShadowDOM so their users get a better user experience.

> 2. You can't create Shadow DOM against text nodes, so if the caret is in `<span>|text<b>bold</b></span>` either the polyfill or the JS editor must change DOM before composition starts.

Check the source code of the polyfill. It is already handled. It simply takes parent element node, adds a copy of all sibling nodes of the text node including hte text node itself and adds them to the shadow root, then discards all of them when done.
 
> 3. And as we discuss here, you need browsers to have a mode for this to work.

We need browsers as a minimum to stick to the current specs and nor worsen them, yes. But this is true for everything. We cannot show videos in the browsers if all the browser vendors suddenly decide to remove video playing features, etc. .

>  If the editor moves selections to replay (I suppose all editors do this today,) it'll break typing experiences either by committing the composition or moving composition.

No, why would you move the selection for that? Moving the selection in order to update the DOM makes little sense in general, but there may be browser bugs that people are working around that I am unaware of. What editor are you thinking of? Moving the selection to do changes to the DOM is not a good idea. There may be some other things you should also need to fix in browsers, but that's not a good excuse for breaking the thing that we just found out are currently possible with IME composition to get a little bit closer to editing sanity. This becomes even more interesting once one can actually really prevent any other DOM changes to take place in the editor so one can rely on only the JS handling it.

> Another likely part is after OT (in your term) was received by other users, how to properly replay it on the other users' browser while s/he is typing compositions.

Changes to the DOM could continue to happen in the background. The user will not see those changes that are made within the same lowest level element node as where the user is typing, but everything else is there. Of course, there is a chance that the changes may cause the Shadow DOM to be destroyed, for example by removing the element that holds the root.In that case the composition will be ended abruptly. But that is the same as when people play "editing wars" using Latin language keyboard and delete the text section where the other user has their caret. It's not that big a problem in real life.

> So my point is that, if an JS collaborative editor has to spend, say, 1 month of dev work to support IME in several functions of the editor anyway, having a filter in the event handler looks more reasonable to me than the Shadow DOM, especially when the polyfill is not perfect as mentioned above.

Ok, but then the polyfill does handle the issue you mention. And not having the polyfill creates the many problems as seen above. Trying to handle partially composed characters and distribute them between users may initially be 2-6 months of work for a good programmer, but it is also a complicating factor that will impact many other future developments within the editor. Not only does one need to keep track of who is typing what, one also needs to make sure that only the user themselves can delete their own partially composed characters. It's just a nightmare to manage, and that's why it's being done so little.  

So really, I think it's really crucial you A) do not break this or B) give us another solution whereby we can get IME input atomically. The alternative is that you spent a lot of time making the browser work with the newest and finest IME, but almost none of the webbased editors will be able to handle any of them.

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