Re: 2 Proposals for Minimum Viable InputEvent

Hi, I'm the maintainer of IME on Android.  I'll be happy to attend the
conference call next week.  As you've surmised, Android does need to
perform a DOM change to merge two nodes "later".  However, I disagree that
those 5 steps are somehow needed.  Our plan is to send a single
insertCompositionText beforeinput event instead of 5 events.

Arguments why each is not needed:

 > 1. deleteByComposition --This step is only needed when recomposing. A
composed word can go across element boundaries, so this may delete more
than just contents of a text node. (fx " He<b>ll</b><i>o fish</i>!"). This
step needs to be executed at the moment your Android IME changes the DOM,
whether this is at the moment the user taps the word and the underline
appears or at a later stage.

There's no need for a separate "delete" event, because
insertion-to-replace-range is general enough to represent a deletion range
as well.  I prefer to reserve "delete" events exclusively for intended IME
deletions (e.g. select word and press backspace).

> 2. insertCompositionText -- Also this step only needs to happen at the
moment only for recompositions. It reinserts the word from step one, but
this time as plaintext in one element (fx "Hello" => "<i>Hello fish</i>")

On Android because of the "late" timing, this merge operation would happen
in the same message loop task as step 3, so there is no need for this
event.  We prefer to go directly from "He<b>ll</b><i>o fish</i>" ->
"<i>Help<i>".

However, rniwa@apple.com has told us that on OS X, the standard platform
behavior is to merge the nodes at time of composition start.  Therefore, on
OS X step 2 is still needed and there would be 2 beforeinput events in
total, but on Android there would be only 1.  This represents a substantive
platform difference that I think it makes sense to allow to differ in the
spec.  I don't think we should try to artificially synchronize the
platforms by always sending 2 events -- on Android this would simply result
in unnecessary work and side effects that would never be seen by the user.

> 3. insertCompositionText -- changes the composiiton (fx "p" with
targetrange above "lo" => "Help"

This one is needed.

> 4. deleteCompositionText -- removed (fx "help"): It removed the text from
the underline and it may not be the entire composition.

> 5. insertFromComposition -- adds "help" permanently, and gives the JS the
opposrtunity to rebuild the complex HTML structure lost in step 1.

Step 3 is already permanent.  The fact that there is still an active
composition underline at the time of step 3 does not make it somehow
temporary.  It has already been injected into the DOM and caused all side
effects.  So the JS should rebuild its complex structure at time of event
3, and events 4/5 are redundant.


>
> The reason you state for the proposed change is that "On Android it’s
> very common for IME to start composition whenever a cursor is moved onto a
> word.  This is primarily intended to passively show an underline to the
> user (to indicate what would be replaced *if* user selects an alternate
> spelling)."
>
> If such tapping leads to actual DOM changes, then  the JS needs to know
> about those(step 1/2). But if you don't change the DOM immediately and only
> do so at a later stage when you "really" start the composition, then you
> can also wait until that stage.
>
>
> So these steps are needed on allplattforms, no matter whether or not you
> change how IMEs work on Android.
>
>
>>
>> Adding aelias@ to make sure he is able to make the call on the 14th.
>>
>> dave.
>>
>> On Fri, Feb 3, 2017 at 1:33 AM, Johannes Wilm <johannes@fiduswriter.org>
>> wrote:
>>
>>> Could we get the person or people who came up with these changes due to
>>> Android to participate in the call on the 14th? I think it's very important
>>> to have them invovled in this discussion.
>>>
>>> On Fri, Feb 3, 2017 at 10:21 AM, Johannes Wilm <johannes@fiduswriter.org
>>> > wrote:
>>>
>>>>
>>>> On Fri, Feb 3, 2017 at 10:18 AM, Johannes Wilm <
>>>> johannes@fiduswriter.org> wrote:
>>>> ...
>>>>
>>>>> Right now I cannot see any purpose of the beforeinput event with these
>>>>> changes applied, but maybe I am missing something?
>>>>>
>>>>>
>>>> I need to restarct that. I guess it could still be useful to stop
>>>> native bold/italic buttons from making their own, non-controlled DOM
>>>> changes. It's just for text input that it is irrelevant. And IME will
>>>> continue to be a mess.
>>>>
>>>> --
>>>> Johannes Wilm
>>>> Fidus Writer
>>>> http://www.fiduswriter.org
>>>>
>>>
>>>
>>>
>>> --
>>> Johannes Wilm
>>> Fidus Writer
>>> http://www.fiduswriter.org
>>>
>>
>>
>
>
> --
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org
>