Re: High-level goals and objectives of the Editing TF (was Way forward and IME behavior speccing

On Fri, Oct 16, 2015 at 9:23 PM, Florian Rivoal <florian@rivoal.net> wrote:
>>
>> On 16 Oct 2015, at 19:11, Koji Ishii <kojiishi@gmail.com> wrote:
>>
>> On Fri, Oct 16, 2015 at 2:34 AM, Johannes Wilm <johanneswilm@gmail.com> wrote:
>>> Hey,
>>> I agree with Florian here. This has nothing to do with disabling through
>>> preventDefault. PreventDefault is used within the space of web based editors
>>> mainly to provide JS editor defined behavior to replace undesired default
>>> browser behavior.
>>>
>>> If one wants to just forbid IME from accessing a site, one would probably do
>>> some sniffing to see if the user is on a mobile device and additionally
>>> redirect the user to a different address when receiving the first
>>> compositionstart event.
>>>
>>> Or to achieve the other behavior where IME just doesn't produce any input,
>>> just cancel the compositionstart, not every single IME-based beforeEdit
>>> event.
>>>
>>> Sorry if that was misunderstood.
>>
>> Thanks for the clarifications, it's good to know. Unfortunately, it
>> still doesn't change the situation.
>>
>> [...]
>>
>> Keyboard, including hardware, software, and IME, are all what user
>> controls, not editors, browsers, nor even OSs. Programs should respond
>> to what user asked.
>
> Depending on which sentence I read, I am not sure if we are it total
> agreement or total disagreement :)

I have exactly the same feeling ;)

> As you said, IME is pretty much the same as keyboard input. preventDefault
> is able to cancel regular input from a keyboard. This is not a plan,
> this is today (see the second example on https://developer.mozilla.org/en-US/docs/Web/API/Event/preventDefault).
> I don't see the argument for being able to  cancel "A" but not "あ",
> or even to be able to cancel "A" if it is input by keyboard, but not
> the same "A" if it is input via IME.

Since the original proposal said "all" and "every single", I'm opposed to that.

If you have specific list of things you want to cancel, I can discuss
on each. Canceling committed characters from IME is fine with me. I
don't read specs, sorry, but I hope we can't cancel Caps Lock, can we?

> And yes, programs should respond to what the user ask. In this case, the
> program which is charged with responding to the user is a js program,
> not the browser. So it wants to respond to what the user asks for,
> not to what the browser wants to do based on what the user asks for.
>
> As part of appropriately responding to user actions, depending
> on the exact situation, it may need to cancel what the browser,
> which is not aware of the full situation, proposed as a default action.

Again, depends on what you're talking about. JS for sure don't want to
handle USB packets, decode it, read the signal of each key, encode to
ASCII, and send back to OS, and make it cancelable. You want
high-level events "this unicode character was typed" and make it
cancelable, that's fine with me.

> There is nothing nefarious or anti-minority about that. It's just about
> protecting the integrity of your data model, and taking the appropriate
> actions at the right time.

I know your intention. As in my another reply, however, it can easily
lead to that situation as a result, and it's also technically hard to
implement across platforms to cancel, for instance, start-composition.

So. Let's be specific. As long as the proposal is about "all" and
"every single", I don't think I'd be convinced. Being specific should
be more constructive discussion.

/koji

Received on Friday, 16 October 2015 14:02:57 UTC