Re: 2 Proposals for Minimum Viable InputEvent

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.

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
>