Re: Way forward and IME behavior speccing

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?



-- 
Johannes Wilm
http://www.johanneswilm.org
tel US: +1 (520) 399 8880
tel NO: +47 94109013
tel DE: +49 176 370 18082