Re: 2 Proposals for Minimum Viable InputEvent

On Fri, Feb 3, 2017 at 4:13 PM, Dave Tapuska <dtapuska@chromium.org> wrote:

> We see a need for beforeinput specifically on Android as the target ranges
> give (and occurring before the mutation) actually give some useful data to
> make that use case viable. Our platform teams raised concerns about the
> remove/insert mechanism that will block us from actually shipping it. To
> make forward progress we proposed what we would like to see in the
> specification.
>
> We have to holistically solve IME not specifically limited to
> contenteditable but in content that isn't necessarily HTML. In games,
> canvases etc. There is some debate as to solve this whether it is a full
> IME API (which I think would solve some cases like apps wanting to provide
> candidates in the candidate window) or using an offscreen text input box as
> mentioned in the document. We don't want to cloud the beforeinput debate
> with these concerns.
>


Thinking more about this, even if you have a fully cancelable IME, you will
still need each of the beforeinput steps:


   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.
   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>")
   3.

   insertCompositionText -- changes the composiiton (fx "p" with
   targetrange above "lo" => "Help")
   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.



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