Re: Way forward and IME behavior speccing

On Mon, Oct 12, 2015 at 5:05 PM, Koji Ishii <kojiishi@gmail.com> wrote:

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


As I understand it, Ryosuke proposes to hide the composition process in the
Shadow DOM during the composition process. I think that is 99% of what JS
editor developers may want (the remaining percent is that they also would
want to control exactly how things look during the composition process). I
think we would be fine with providing these 99%. So I would be completely
in favor of doing this.

However, the ShadowDOM approach has been attacked on several fronts:

- The approach where text nodes cna be hosts for Shadow DOM root, by
Ryosuke who doesn't think this is feasible. He does instead suggest to use
the lowest level parent element as Shadow DOM host.

- The browser-controlled Shadow DOM by Ojan who says it's not performant
and that we should instead just make sure that the same movement to the
Shadow DOM can be in JavaScript.

- The JavaScript-controlled Shadow DOM approach by the UI events people
(Koji and masayuki-nakano), who, if I understand you correctly, believe
that JavaScript should not be allowed to move the caret somewhere else
during compositionstart.


So taking these three arguments together, the Shadow DOM approach is not
possible. Please let me know if I misunderstood any of you on this.



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

Well, as mentioned "Consider re-conversion, that turns existing text into
composition" [1], on Android, one can click on a word and then that word is
moved back into the IME composition and can be edited there. So the outcome
of that operation when the composition is finished is that word A has been
turned into word B, ie "edited".

This seems to also work if word A is a more complex HTML structure, such as
"<b>A<b/>pple". But trying this out on TinyMCE and CKeditor, it simply
seems to replace the entire thing with a string "Apple", even if the user
just clicks on the word once without editing any of it. Not sure how much
this is cE itself and how much is CKeditor/TinyMCE.


>
> 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.
>
>
Yes, so it is already editing HTML more complex than just text nodes. It
may just be replacing more complex DOM structures with text nodes, but that
is still messing with the DOm and it is still soemthing that JS editor
developers need control over.


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

Well, as said, it's doing arbitrary things and seems out of control. Either
we control it or we say that for this new editing mode, it is either
strictly adhering to specific specs or it is only allows to add/edit/delete
text nodes. If we are in a situation where all web developers need to test
their editing apps with every possible browsing device because IMEs behave
differently everywhere, then we are back to where we started.


>
> /koji
>

[1] https://github.com/w3c/uievents/issues/5#issuecomment-137164382

-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org