Re: Way forward and IME behavior speccing

2015/10/14 6:05 "Ryosuke Niwa" <rniwa@apple.com>:
>
>
> > On Oct 13, 2015, at 6:14 AM, Johannes Wilm <johannes@fiduswriter.org>
wrote:
> >
> > A) In this new mode we continue to entirely forbid IMEs to deal with
more than just the contents of a text node. If the IMEs are unaware of DOM
structures, then surely this must be in the browser code that glues it to
IMEs. The user experience will be slightly worse for a few cases (auto
correct will not work on partially styled words), but it will be a major
improvement for all other cases and it will do that JS editors will not
just break randomly when dealing with IMEs.
>
> This is not acceptable because it would significantly hinders user's
ability to edit text.

Agreed.

> > B) We make all of these IME-introduced changes preventDefault'able.
IMEs will just have to be able to handle this if they want to be standards
compliant. Also, may not a lot of this be doable creatively in the
glue-code? If the IME doesn't allow preventDefault, but the default action
is canceled in JS, couldn't the glue code simply abort the current IME
operation (tell the IME that composition has been finished) and then start
it again immediately thereafter and starting out with the text as it is
after the JS defined operation. To the JS code that would make it look as
if IME input would be preventDefaultable.
>
> This is probably possible because browsers do have the capability to
cancel the current composition as needed on both Mac and Windows (and
likely Linux).

I don't agree with this. All IME actions being cancelable means almost the
same as A to me. It's quite possible to create a situation like this editor
doesn't work for Japanese, that editor not for India, and many editors do
not work on Android because they cancel reconversion request.

/koji

Received on Wednesday, 14 October 2015 08:52:24 UTC