Re: Way forward and IME behavior speccing

I'm not sure we're moving towards to the right direction.

I wasn't in the discussion, but what I remember was that the TF moved from
ce=events to ce=typing because with events, JS has to handle all IMEs and
composited characters, and Ben said that JS developers wanted to avoid that.

If ce=typing needs to define and handle all IME related complications, it
looks to me that we lost something. Not sure what we missed, but my
preference is to discuss to find a way without defining everything related
with IME.

Do you have a list of issues why you need to handle IME, so that we could
try to find a way without defining it?

/koji

On Sat, Oct 10, 2015 at 12:41 AM, Johannes Wilm <johannes@fiduswriter.org>
wrote:

> Hey,
> as you all will know, we had quite a productive F2F meeting in Paris in
> connection with the CSSWG at the end of August.
>
> Unfortunately a few more issues appeared just after the meeting had
> concluded, principally issues the browser makers found after concluding the
> meeting that had not come up during the meeting itself. We hope to be able
> to clarify all these points during the Wednesday of TPAC [1].
>
> The issues are:
>
> -- The name of the events (beforeInput/Input or beforeEdit/Edit). [2]
> -- What is the complete list of edit operations for
> beforeEdit/beforeInput? [3]
> -- Complications related to IME input. [4]
>
> Particularly IME input seems to be an evergrowing problem. We already had
> to move from cE=events to cE=typing, which is a odd mode in that it only
> allows character input, and deletion, but deletion only during IME
> composition. But now it seems that even that is not enough, that IME input
> need to be able to arbitrarily change the DOM and that IME composition
> cannot in any way be restricted. Also, IME is working differently on every
> platform and with every IME engine and a lot of IME interfaces are
> apparently constantly on the brink of breaking.
>
> To me this all sounds as if IME is like Flash, just that there are 30
> different versions of it now and need to accommodate those + 150 future
> versions whose functionality is not yet known . Ie - it's not a situation
> that is viable in the long term. And because the usage of IMEs is expanding
> (on Android everything is IME), the only way to kill the monster is to
> start speccing the behavior of IMEs and to make sure they  all are
> restricted in their behavior and that their behavior is standardized.
>
> The IME API [5] does not seem to talk about any of that. The question is:
> Is this a document that still needs to be made, or is it already happening
> somewhere else?
>
>
> Btw, to me it seemed that one of the more important points is to sandbox
> the IME [4], but as I understand Piotr (CK Editor), that is not necessarily
> enough -- being able to cancel or modify individual composition operations
> (including deletions) would be more important.
>
>
>
> [1]
> https://www.w3.org/wiki/TPAC/2015/SessionIdeas#Text_editing_in_the_browser
> [2] https://github.com/w3c/editing/issues/87
> [3] https://github.com/w3c/editing/issues/79
> [4] See for example
> https://github.com/w3c/uievents/issues/5#issuecomment-137559461
> [5] http://www.w3.org/TR/ime-api/
> --
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org
>