Re: composition events and focus changes

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?

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?




>
> 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