Re: Way forward and IME behavior speccing

On 14 Oct 2015 10:51 am, "Koji Ishii" <kojiishi@gmail.com> wrote:
>
>
> 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.
>

Yes, it is certainly possible to program an editor so it doesn't work on
Android, etc. . But that will always be the case. If you add more
difficulties to JS editor developers they will just do as now and
concentrate all their efforts on the most basic stuff with keyboard input
and just leave out IME input, vertical writing mode, etc. entirely.

The other option is that the browser makers add perfect editor components
to their browsers, each hirering dedicated fulltime richtext editor
development teams with the resources to give the level of customer support
and quick fixes to bugs that projects such as CKeditor, TinyMCE, Aloha
Editor, ProseMirror, Fidus Writer, Codemirror, Wikimedia editor,
substance.io, etc. .that does not seem realistic in the near future, so we
need to work here on giving the developers of such projects the power to
solve the problems.

I am at the Frankfurt Bookfair with limited net access, but I really liked
Ryosuke's last suggestion about giving information back to the browser
about what sections are "unclean" (for spell checking, auto correction) and
also something similar for manually changed IME-input.

Also Florian's idea of a wiki i like. Do we have the infrastructure to set
that up already?

I will be back after the bookfair.