Re: Way forward and IME behavior speccing

Ok, well the way Piotr used the term, which I borrowed, was to mean
something like "the practice of moving the focus/caret to some place that
is not part of the DOM that makes out the editor during the time that
composition takes place so that the JS can clean the result before
inserting it on the editor part of the DOM". "Some place" can be either
some other place in the DOM, the ShadowDOM, or some non-DOM-defined place
that may be available in the future.

But the need for this process, whatever we call it, was based on changes
from IME not being canceable, whereas keyboard and all other types of input
could be cancelled/user definable.

Now if we can go back to cE=events as you propose and so IME-based input
will be canceable just like any other input, then the need for this will
likely not be as urgent either.
On 21 Oct 2015 2:48 pm, "Ryosuke Niwa" <rniwa@apple.com> wrote:

>
> > On Oct 21, 2015, at 1:03 PM, Johannes Wilm <johanneswilm@gmail.com>
> wrote:
> >
> > On Wed, Oct 21, 2015 at 10:16 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
> >
> >> On Oct 21, 2015, at 12:05 AM, Johannes Wilm <johanneswilm@gmail.com>
> wrote:
> >>
> >> On Tue, Oct 20, 2015 at 8:28 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
> >>>
> >>> > On Oct 14, 2015, at 9:24 PM, Johannes Wilm <johanneswilm@gmail.com>
> wrote:
> >>> >
> >>> ...
> >>> >
> >>> > This is only one of the options, if we cannot get any better
> controls on IME. If we can get preventDefault, if we can influence what the
> IME considers a word when moving text back into the IME for editing, if we
> can sandbox it and only get an atomic commit, then we don't need that.
> >>>
> >>> I think that would be hard because a part of IME's job is to figuring
> out where word boundaries occur. In both Chinese and Japanese, word
> boundaries can never be precisely determined because they're context
> sensitive (e.g. there is no dedicated character or a sequence of characters
> that denote start or end of a word).
> >>>
> >> Right. but JS may know something more about certain DOM element
> boundaries which won't let words cross them. That's why in an ideal version
> I would like to be able to influence the idea the IME had about word
> boundaries. And I think that should be possible without destroying anything
> for Chinese/Japanese: IME says where it thinks the word is, and JS has an
> opportunity to to change that (but doesn't have to).
> >
> > No, that would require synchronous callback to JS.  We need more
> declarative approach where apps would specify where the boundary should or
> should not occur at each element boundary instead.
> >
> >> But in the latest few emails, I was actually asking for even less for
> this first version. Instead of letting us influence where those word
> boundaries occur, let us at least know where these word boundaries are in
> the DOM once you have found them (in the form of a range).
> >
> > We can't expose every word boundary in IME as that would be a privacy
> concern as I've previously pointed out.
> >
> >> Right now we already get the contents of the word that was found as the
> data attribute of the compositionstart event. And we know where the caret
> is. So it is possible to find out what rnage that corresponds to, but it's
> quite a lot of work. Consider this case:
> >>
> >> <p>This is a sentence with <b>a part</b>ia|l<i>ly styl</i>ed word.</p>
> >>
> >> | = caret
> >>
> >> Now composition starts on Android/iOS and the compositionstart event's
> data attribute is "partially". Yes, we can probably figure out what range
> that corresponds to already now in JavaScript by going back and forth in
> the DOM until we have found enough letters in text nodes that correspond to
> the given word, but it would be much simpler if the browser would just
> directly hand that information to us.
> >
> > This is a slightly different issue though.  In the case of
> compositionstart (and other composition events), it's totally fine to
> expose a Range that encompasses what data attribute contains since the user
> had already typed those in (there is no new information exposed by this).
> >
> > Well, this is what I am talking about. If we can agree on that, then we
> are all set.
> >
> >
> >>
> >>> I don't think disabling any IME feature is acceptable.  Again, IME
> behaving differently in Web apps and native apps is going to provide a
> horrible experience for end users.
> >>
> >> Right, I think if we can agree on JS being allowed to sandbox IME, the
> way we had talked about at the last F2F, then most of these issues will not
> be as important.
> >
> > Please stop using the word "sandbox".  "Sandbox" has a very specific
> meaning in HTML, and it's very confusing.  This is all about IME not
> directly affecting DOM, let's keep at that.
> >
> > I am fine with switching to another term. What term would you propose we
> use for this?
>
> I don't think there is no single term for it.  It's simply a principle
> that IME or the rest of browser features should not directly modify DOM.
>
> - R. Niwa
>
>