RE: composition events and focus changes

Since we talked a little today about extending Composition Events with some contextual range info, I finally *did* find the spec where this had been attempted—the “annex” of the IME specification: http://w3c.github.io/ime-api/Annex.html#compositionevent-interface


Now, specifically, I did run the below mentioned test in Edge (not our latest version, but the currently shipping version), and here are the results:

Edge appears to work a lot more like Firefox than Chrome in this case—the composition session is terminated and then re-started on the new target node. No composition characters are transferred to the new node. There was a bit of non-determinism on my part, and I’m not very confident in the results, but we can review tomorrow if anyone’s interested.

-Travis
---------- Forwarded message ---------
From: Ojan Vafai <mailto:ojan@google.com>
Date: Mon, Oct 19, 2015 at 1:26 PM
Subject: composition events and focus changes
To: mailto:public-editing-tf@w3.org <mailto:public-editing-tf@w3.org>

I'd like to get us back from our state of questioning everything we're doing and focus on seeing if our current tack can be saved. IMO, we're very close to something finished and should try not to change course if we can.

I would like to end up in a world where we spec low-level IME apis, but that's a big project and not one that we should take on without more staffing from a browser vendor committed to designing and implementing them.

Here's the TL;DR of my preferred path forward:
1. Spec the current Chrome/Safari behavior. This will make the JS authors happy and will not hurt IME in any way (see below for details).
2. Publish good documentation about how to use composition events and about common pitfalls (e.g. moving the cursor to a different place in the text). This will both make JS authors happy and improve IME support on the web.

I'm making two key assumptions:
1. Keeping IMEs working correctly is non-negotiable. Any API we design needs to work correctly to the extent that is reasonably possible. That doesn't mean that every combination of actions needs to do what a user expects. For example, even in a non-IME world, a JS author can do crazy things on every keypress. There is no way to guard against that. There's not even a way to make that hard to do.

I'm not 100% sure, but I believe that this *does* imply that we can't make preventDefault work for all IME input.

2. Giving JS authors complete control over DOM modifications is non-negotiable. Any author who has worked on a JS library can see the desperate need for this. It's just fundamental to having a decent editing platform. This does not, however, mean that the author needs to be able to preventDefault all actions.


DETAILS
I think it's clear that https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fw3c%2fuievents%2fissues%2f5&data=01%7c01%7cTravis.Leithead%40microsoft.com%7c8dd5cfcecebe403ef9ed08d2dea2ad70%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6XcrYqEIHx8ReUApEfmDfou2uV6YLnRBSvtk0eVSfxQ%3d would address #2, but there are concerns on that issue that it would break #1. Those concerns don't make sense to me. That's not because I think breaking IMEs is OK (I don't!).

A. This is already how Safari and Chrome work. I can't find any bugs about IME being broken due to this. It's not a problem in practice. And Firefox's behavior here is clearly bad IMO (the IME stays open and you can keep typing into it, but none of the changes are reflected in the DOM). I don't have IE on hand to test what they do. I tested on Mac with a pinyin-based IME. Here's my test case: https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fjsbin.com%2fpovobotere%2fedit%3fhtml%2cconsole%2coutput&data=01%7c01%7cTravis.Leithead%40microsoft.com%7c8dd5cfcecebe403ef9ed08d2dea2ad70%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ZlBup9egE7uweJEsOnCz8GCnUDtA%2b4groIgGXyF%2bGvc%3d


B. Moving the selection in the DOM is only a problem if you move it to a different text location. If you keep it in the same text location, but wrap it in a span or put it inside a shadow DOM, then the IME continues working as expected. Clearly there was agreement on the shadow DOM version of this since there was previous agreement on magically doing this with shadow DOM before.

The reason I don't think B is a problem is that there are a million other ways of moving the selection mid-composition (e.g. you can move it during keypress). We're not creating a new problem.

Also, it's only the really expert web developers that use composition events. So good documentation can have a very big impact here. The best thing we can do for better IME support on the web is to focus on creating really great documentation about right and wrong ways to support IMEs. Limiting composition events from doing something other events can already do doesn't solve any problems.

Masayuki-san also had a concern on that bug that we'd be breaking expectations of what composition events do because you wouldn't have a guarantee of compositionend always firing on the same node compositionstart fired on. I agree that's less than ideal, but it's consistent with other events (e.g. key events). More importantly, it's how Safari and Chrome work today and we have never once gotten a bug report about this that I know of. It's just not a thing developers depend on or care about in practice. Lastly, I'd like to reiterate that Mozilla's current behavior maintains the compositionstart/compositionend pairing, but the user experience is really broken. So there's no backwards compatibility concern here that I can see.

So, I think there are two things that need specifying here and IMO in both cases the Safari and Chrome behavior is really reasonable:
1. What happens when you move focus during composition start? == The composition starts where you moved the focus to.
2. What happens when you move focus and there is a composition in progress? == The current composition is committed and a new composition starts where focus was moved to, but contains all the previous composition text as well. This has the advantage of not messing with the IME's internal state too much since the composition text doesn't change.

#2 is a thing people really shouldn't be doing, but we may as well agree on the best we can do here, which the current Safari/Chrome behavior seems pretty reasonable to me.

Received on Tuesday, 27 October 2015 11:13:18 UTC