Re: cancelability in level 1 of input-events spec

Hey Alexandre,
as far as our agreement hitherto had been, only a few of these will ever be
triggered during IME, and those are exclusive to IME. So in other words:
those input types that are used in IME are not used outside of it and vice
versa. I understand that on Android, a lot of things have been wrapped in
IME, which seems like a different problem that we hopefully will resolve
once we get more control over the IME process.

In effect it would mean that on Android, most of the inputTypes would
likely not be in use. For example -- on some desktop OSes there are special
keyboard shortcuts for operations such as deleting from the caret position
to the next softline wrapping. On other OSes without such a keyboard
shortcut, these inputTypes would not be triggered at all.

> because "Paragraph break" and "Delete word backward" are plain-text
operations

Not necessarily. If a word is partially styled, then deleting that word may
mean several other DOM changes. SImilarly, if the caret is in an
italic-styled part of a line that is not fully styled, deleting to the end
of the line will not just be a plaintext operation.


The examples I mentioned were just randomly chosen. We'll need to build a
strong argument fro JS devs to be using the beforeinput event, and the part
about why some things can be canceled while others cannot still seems a bit
weak.

On Tue, Jun 27, 2017 at 12:40 AM, Alexandre Elias <aelias@chromium.org>
wrote:

> The philosophy is indeed that an IME might send it, and we erred a bit on
> the side of conservatism on the list to avoid locking ourselves in a bad
> situation if an IME does wind up sending it.  IMEs do not understand rich
> text nor the clipboard so it was safe to exclude ordered lists and "cut".
> But they have a wide variety of APIs to alter plain text, and because
> "Paragraph break" and "Delete word backward" are plain-text operations (in
> contenteditable, simple plain-text carriage returns might be mapped to
> <p>), it's possible one of them might send it.
>
> I'm not totally opposed to making these 2 cancelable if there is a clear
> use case and we can guarantee that we never map IME operations to it but to
> an alternate event, though.  Or if the problem is mostly confusion rather
> than a use case, we can explain the reason is "plain textiness ~= IME".
>
>
> On Mon, Jun 26, 2017 at 2:17 PM, Rick Byers <rbyers@chromium.org> wrote:
>
>> +aelias.  Personally I really hope we can achieve interop around all this
>> :-)
>>
>> On Mon, Jun 26, 2017 at 4:43 PM, Johannes Wilm <mail@johanneswilm.org>
>> wrote:
>>
>>> Hey,
>>> the TAG review of the input events spec asked us among other things to
>>> convert the long list of inputType values to a table. I have now done that
>>> for both levels. Now that I am done I get a clearer picture of which iof
>>> the inputTypes the Google people decided to not make cancelable in the
>>> level 1 version. They are marked as "Undefined" so that also those
>>> implementing level 2 are compliant with level 1. [1]
>>>
>>> I wonder though -- what made you guys decide to make exactly those not
>>> be cancelable? For example, inserting an ordered list can be canceled, but
>>> inserting a paragraph break cannot be canceled. Neither one of these should
>>> be happening during an IME composition, right? Or if I hit a special key
>>> combination to delete a word backward, that cannot be canceled. But if
>>> instead I select the word and hit the key combination for cut, that is
>>> cancelable.
>>>
>>> Is this list meant to be final or is this still work in progress? If
>>> this is final, then maybe it would be a good idea to write up soem
>>> explanation fro the philosophy that lies behind these choices. Otherwise I
>>> am sure a lot of JS devs will be just as confused as me about this.
>>>
>>>
>>> [1] https://rawgit.com/w3c/input-events/v1/index.html#h-inte
>>> rface-inputevent-attributes
>>>
>>>
>>>
>>>
>>> --
>>> Johannes Wilm
>>> http://www.johanneswilm.org
>>> tel: +1 (520) 399 8880 <(520)%20399-8880>
>>>
>>
>>
>


-- 
Johannes Wilm
http://www.johanneswilm.org
tel: +1 (520) 399 8880