Re: Way forward and IME behavior speccing

> 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

Received on Wednesday, 21 October 2015 05:48:42 UTC