Re: Going back to contenteditable=events

> On Oct 24, 2015, at 4:45 PM, Johannes Wilm <johannes@fiduswriter.org> wrote:
> 
>> On Sat, Oct 24, 2015 at 4:20 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> 
>>> On Oct 24, 2015, at 12:01 AM, Johannes Wilm <johannes@fiduswriter.org> wrote:
>>> 
>>>> On Fri, Oct 23, 2015 at 10:27 PM, Koji Ishii <kojiishi@gmail.com> wrote:
>>>> We had some discussions internally today. While I expect us to discuss more details next week, here are some short updates:
>>>> Ryosuke's approach looks interesting, we'd like to learn a little more details next week.
>>>> Re-confirmed that canceling compositionstart does not work on some platforms, so it's a choice of not to allow cancel, or cut off interoperability on some such platforms.
>>> 
>>> What platforms are those? And is this because of the IME are incapable of being made to work this way or because the browser implementations of the current spec is broken?
>>> 
>>> I think it would help a lot to know which platforms we are talking about when making such decisions.
>> 
>> Why is this an issue at all if we're letting JS modify DOM?  You can't cancel regular key down/press either in a sense but that doesn't prevent authors from having full control over DOM, right?
> 
> 
> I have a feeling we must be talking about different things. 
> 
> If a user presses a key, in Javascript I can do preventDefault on that event so that the DOM never changes. 
> 
> The same is not true for IME input.
> 
> I can (currently) cancel compositionstart - but then I don't know what input would have been inserted had I let it continue, so in most cases this is not very useful. Anyway, this is what Koji apparently wants to take away.
> 
> At any stage beyond compositionstart, I can not cancel the input. The IME modifies the DOM and there is nothing I can do about it, unless I am missing something.

In my proposal, IME never directly modifies DOM.  We simply send a request to JS like we do for other editing actions.

Essentially, what I solved with my proposal is the problem of IME composition having special underlines.  Instead of WebApps applying those styles to text nodes, Web browsers are detecting where the composed text appears in DOM and automatically styling it.  This nicely avoids the problem of exposing various composition states to the app.

With that, IME no loner has to be anything but special editing action.  It would be just another editing action for which we let WebApps modify DOM.  The only thing we do differently is that we automatically style the current composition that appears right before the caret.

> 
> This is why keyboard input is something the editor has full control over, whereas IME input the editor has almost no control over.
> 
> But I am sure you know this and I'm just repeating the obvious.. So I'm wondering if you meant something else than what I read into the phrase "cancel regular key down/press", etc. .
>  
>> 
>>>> Moving focus during compositionstart may work if we can limit it to some criteria, such as:
>>>> To non-replaced elements/text nodes.
>>>> Only during compositionstart.
>>> 
>>> So not at compositionend? We would need that as well.
>>>  
>>>> 
>>>> There are no composition string (i.e., discussed about partial-commits; we were not sure how well partial-commits are defined nor interoperable though.)
>>> 
>>> So in other words: This would not work on recomposition for Android/iOS?
>>>  
>>>> 
>>>> The screen position of the caret does not change (i.e., inserting empty div and moving into it will not move.)
>>>> Shadow DOM is likely to cause some technical issues. It's workable, not sure worth.
>>>> These criteria looks ok for the Johaness's use case to me, unless I miss something.
>>> 
>>> If I understand this correctly, it solves one problem: Creating an <ins> or a <strong> node or alike when new text is typed that will contain the new text.
>>> 
>>> But it does not solve the more fundamental problem of having the JS editor keep control of what goes into it's part of the DOM and being able to do atomic commits.
>>> 
>>> Do I read that correctly? In that case, I think we need to try a little harder. If this is a matter of having to spend a little more time to make the caret be movable to the Shadow DOM in a specific browser, I think is time you will need to invest. Otherwise we create a spec that will be almost as problematic as what we currently have, and with more and more text input moving from direct keyboard input to some form of IME, we will be back trying to fix the same problem with a new spec in six months or so.
>>> 
>>> 
>>>  
>>>> /koji
>>>> 
>>>>> On Thu, Oct 22, 2015 at 1:51 AM, Johannes Wilm <johannes@fiduswriter.org> wrote:
>>>>> 
>>>>> 
>>>>>> On Wed, Oct 21, 2015 at 2:42 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>>>>>> Hi all,
>>>>>> 
>>>>>> == Background ==
>>>>>> 
>>>>>> I've been thinking about various problems about IME, and I think we should go back to contenteditable=events because letting Web browsers make any DOM mutations is a slippery slope.
>>>>>> 
>>>>>> We went with contenteditable=typing because the composition text had to be rendered differently than ordinary text and we couldn't expose every IME state (e.g. candidate states).  But there is an alternative approach that doesn't invoke DOM mutations.
>>>>>> 
>>>>>> We (Apple) have also found another issue with the current design. We need to remember when autocorrections are reverted by the user (via undo). In order for features like these to work, we need to attach meta data on text the user had typed. Furthermore, single text node model of IME doesn't work for more advanced text editors; e.g. one with a custom justification algorithm which needs to replace each character in a separate div.
>>>>>> 
>>>>>> == Proposal ==
>>>>>> 
>>>>>> 1. We make all IME actions/commands simply requests from Web browsers.  JS will have full control over what it does with those requests.
>>>>>> 2. Web browsers automatically stylizes and remembers meta data for the typed text based on caret (collapsed selection) location and innerText of the closest editing host (root editable node).
>>>>>> 
>>>>>> (2) is the key. Instead of browser taking the control of what's happening in IME, etc..., we'll get the state out of the Web apps. We would treat everything in the current contenteditable=events (except contenteditable=false contents) as the pre-existing text + user edited text.  This will allow browsers to map the current content with what the user had typed, etc... This should work 99% of the time when the apps are respecting browser/user issued IME requests.
>>>>> 
>>>>> Do I understand correctly that the browser will keep a copy of the text as it was when the browser page was initiated and will then once the page changes simply compare the copy it kept with the current state and assume that anything that was not there at the beginning was added by the user in the current session? And it will then turn of spell checking, auto fixing for those parts of the text that have been edited by the user in the current session? Or the other way round?
>>>>> 
>>>>> 
>>>>> This all sounds good to me in general, but a few smaller remarks/questions:
>>>>> 
>>>>> A. Earlier it was said that ti would be very hard to cancel IMEs or not to allow their input directly into the DOM. I assume you have found a new way that would make this possible? Do all the browser people agree that this is possible?
>>>>> 
>>>>> B. The hierarchy of modes we decided upon were, AFAIR: events, caret, typing, true/all. The difference between caret and event is that caret will include browser based caret movement. We had some back and forth with the JS editor people where Koji's and my position was that block direction caret movement would not be so difficult to implement in JS [1], but JS editor developers from CKeditor and Prosemirror/Codemirror seemed to like the idea better of this being controlled by the browser. So before switching to cE=typing, I think the last mode we focus on was cE=caret. So my question is: Should we switch back to caret or to events?
>>>>> 
>>>>> C. What could such an IME interface look like for the JS developer? We would get a composition start event and a series of other beforeInput events that have no default action. We then need to write JS to actually make the individual characters appear where the caret currently is, correct? The IME would assume that we display the characters it produces in the place where the caret was before compositionstart and no matter whether we actually put them there or not, will act as if we did, right?
>>>>> 
>>>>> So we might get something like the following events in this order:
>>>>> 
>>>>> 1. compositionstart (no default action)
>>>>> 
>>>>> 2. beforeInput/Edit replaceContent event w/ isComposing: true and targetRanges: range that covers the word that is to be replaced
>>>>> 
>>>>> 3. beforeInput/Edit insertCharacter
>>>>> 
>>>>> 4. beforeInput/Edit insertCharacter
>>>>> 
>>>>> 5. beforeInput/Edit insertCharacter
>>>>> 
>>>>> 6. (user wants to go one position to the left within the composition) selectionchange event
>>>>> 
>>>>> 7. beforeInput/Edit deleteContent, data: 'backward'.
>>>>> 
>>>>> 8. beforeInput/Edit insertCharacter
>>>>> 
>>>>> 9. compositionend
>>>>> 
>>>>> Right?
>>>>>   
>>>>> D. Would this work even if we don't actually put the things into the DOM the way it had been imagined? How about the selectionchange event -- I assume this is something the IME will have to know about as well?
>>>>> 
>>>>> E. How about the underline? Is this something we will have to add ourselves (and be able to do), or will the browser simply assume that all added content between compositionstart and compositionend is part of the composition and will therefore be underlined during the time of the composition?
>>>>> 
>>>>> 
>>>>> 
>>>>>  
>>>>>> - R. Niwa
>>>>> 
>>>>> 
>>>>> [1] https://github.com/w3c/editing/issues/65
>>>>> 
>>>>> -- 
>>>>> Johannes Wilm
>>>>> Fidus Writer
>>>>> http://www.fiduswriter.org
>>> 
>>> 
>>> 
>>> -- 
>>> Johannes Wilm
>>> Fidus Writer
>>> http://www.fiduswriter.org
> 
> 
> 
> -- 
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org