Re: 2 Proposals for Minimum Viable InputEvent

I don't think that works. An API for IME would be great, but this is years
into the future, right? Also, how are we supposed to say whether or not
what you are proposing is as good as what we have with the beforeinput
event if the discussion of that other thing doesn't happen here?

If there is any point in us non-browser people spending years of our lives
discussing things with you here, there must be a minimal understanding that
we are taken half-way serious when we talk about the problems JS editor
developers have with cE. Otherwise you don't really need us, do you?

Also, you are crippling the beforeinput event for keyboard input for no
good reason.

We have now for years tried to fix cE. We have collectively come to the
conclusion that it cannot all be fixed in one go. If you actually get to
create a IME API some time in the next 40 years, I would expect you that
IME to give out new, cancelable beforeinput inputtypes that will be
documented in a future version of the input events spec.

(Sorry for spelling errors. I am typing this on  Android with Google
keyboard, so I can't go back and fix things as the IME tends to destroy
entire sentences when I try to recompose asingle word.)

On 3 Feb 2017 3:13 p.m., "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.
>
> 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
>>
>
>