Re: composition events and focus changes

On Tue, Oct 27, 2015 at 10:38 PM, Johannes Wilm <johannes@fiduswriter.org>
wrote:

>
>
> On Tue, Oct 27, 2015 at 8:12 PM, Travis Leithead <
> travis.leithead@microsoft.com> wrote:
>
>> 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
>
>
> If I remember correctly, the experimental implementation of the IME API
> was implemented in Chrome was removed recently due to low usage, correct?
> Is it still in IE?
>
>
For Chrome, right, the experimental implementation was removed for now.
For IE, I think it is still there (but some interface only works in Metro
mode).



> As for the offsets: I see that the information on where the composed word
> is given in terms of offsetvalues of the textContent of the parent element
> (compositionStartOffset and compositionEndOffset) rather than as a range. I
> assume this is done in order to give a uniform interface for both input
> elements, textarea and contentEditable?
>
> I wonder though, say I have the following element inside a contentEditable
> element on an Android device:
>
> <p>This <img ...><i>is <svg>...</svg> a par</i>a<b>graph.</b></p>
>
>
> And I hit the word "paragraph" with my finger. It would give me the
> compositionStartOffset = 11 and compositionEndOffset = 19 on the target
> <p>-element, correct?
>
> This information is already better than what we have now at composition
> start, but if we are in contenteditable, would it be much trouble to also
> give us the range that corresponds to? And if the entire IME API isn't
> going to be implemented, maybe we could get that at compositionstart
> instead?
>
>
The Chrome implementation, compositionStart/EndOffset only worked for
<input> and <textarea>,
did not work for contenteditable IIRC.

If we were to calculate compositionStartOffset in contenteditable that way,
it would be very costly
operation.



>
>
>
>>
>> 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.
>>
>
>
>
> --
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org
>



-- 
Takayoshi Kochi