Re: Way forward and IME behavior speccing

On Mon, Oct 12, 2015 at 11:07 PM, Johannes Wilm <johannes@fiduswriter.org>
wrote:

>
> On Mon, Oct 12, 2015 at 2:46 PM, Koji Ishii <kojiishi@gmail.com> wrote:
>
>> I basically agree with rniwa. Let's focus on things that bothers editor
>> JS developers today. "Not messing DOM at all" itself shouldn't be our goal,
>> it should be "only where it really bothers."
>>
>
> I'd wished you had been at the F2F, even via voice call or via IRC. The
> argument that has been made over and over again over the past year and a
> half is that JS editor developers need to have the last word on what kind
> of change is being made to the DOM upon user input. That's what this task
> force is about. That's why we will have the beforeInput/beforeEdit event.
> As has been argued before, it is the only good way to ensure in the short
> term to have the same HTML produced on editors running different browsers,
> without having to resort to complex tools such as DOM diffing mechanism,
> etc. on the part of the Javascript.
>
> Then, once we have this, we can start looking at standardizing other types
> of behavior, including things like paragraph breaking, etc. -- implementing
> it entirely in JavaScript and possibly, in a long term persepctive of 10-50
> years, by also making web browsers adhere to some standardized version of
> cE=true.
>

I think I understand that, but I don't connect this thing to needing to
standardize IME. I can agree with what rniwa saying:

> What we need is an abstraction which hides all these platform-dependent
IME behaviors.

Do you see what I miss?

Also let's not worry too much on future, today's IME API cannot submit
>> HTML. Fixing is easier than preventing.
>>
>> Right, if we can just say that IMEs can only create text nodes, edit them
> or delete content from them, then we have no problem at all.
>

In terms of creating, I think inserting text into existing text node is the
only thing keyboards can do with IME or without IME. Were there any
discussions in Paris that IME has more capabilities?

"edit them"...I don't understand this. Isn't all the primitives insert and
delete?

For deletes, I think last discussion with Ben was that we might need to
delete more than text, and there was an issue for that. I'm sorry that I
didn't follow what happened to that issue since then.

But if we are prevented from saying that because future versions of IMEs
> need to author HTML, then we need to spec exactly what they can author and
> how they do it. Just leaving IMEs to do whatever unspecced thing is not
> bringing this forward.
>

I'd be happy to discuss on issues where IME bothers JS developers today,
and how to solve those issues by making abstractions. But I'm not positive
to start from abstracting and spec'ing IME. That'd be a huge work.

/koji