Re: cancelability in level 1 of input-events spec

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>
>>
>
>