Re: composition events and focus changes

On Tue, Oct 20, 2015 at 11:37 AM, Koji Ishii <kojiishi@gmail.com> wrote:

>
>
> On Tue, Oct 20, 2015 at 3:47 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>
>>
>> > On Oct 19, 2015, at 1:26 PM, Ojan Vafai <ojan@google.com> wrote:
>> >
>> > 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.
>>
>> I also agree with both of these points.
>>
>
> I agree too.
>
> There's one minor point I'd like to confirm our consensus.
>
> What are our stance when 1 and 2 conflicts?
>
> Giving JS authors complete control of whatever browsers have full control
> over is in consensus.
>

Letting us sandbox the IME should resolve most issues in thsi case. The IME
behaves as it would always behave, yet the JS has the last word on how the
text is moved back into the part of the DOM that makes out the editor.



>
> During composition, however, IME owns some controls and there's nothing
> browsers can do. Oftentimes IME is the master and browser is following its
> orders. For instance, MDN[1] states that "some platforms don't have an API
> for canceling composition." Some IME flushes compositions when system focus
> is moved, so if we define behavior on focus move, we may need to make sure
> system focus is not affected, but I'm not sure if this is possible on all
> platforms at this moment.
>
> For those possible platform differences, I prefer abstraction than giving
> control so that JS works across platforms. In a big picture, this might be
> a sub-item of Ojan's item 1, but it may be considered to hinder item 2 at
> some levels. That's what I meant by "conflicts" above.
>

If none of us know what IMe this is about, maybe we should find the person
who wrote this on MDN and ask that person? I would still say that if there
happens to be an IME on OS/2 from 1993 that requires the user to turn the
computer off for three days before it cancels the composition, then we
should be able to say that that IME does not provide the minimum features
that are needed in order to work with a standard compliant web browser,
instead of saying that we have to allow everything and anything than an IME
may or may not do, even if we cannot find any common IME for which that
applies.


As Ojan pointed out, if we move the caret during compositionstart, we want
the composition to still work as if the caret had not moved -- so context
related words, etc. should appear just as if the caret had not moved. I
would imagine that should make it easier to provide, shouldn't it?


>
> Thoughts?
>
> [1] https://developer.mozilla.org/en/docs/Web/Events/compositionstart
>
> /koji
>



-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org