Re: Going back to contenteditable=events

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.
   - Moving focus during compositionstart may work if we can limit it to
   some criteria, such as:
      1. To non-replaced elements/text nodes.
      2. Only during compositionstart.
      3. There are no composition string (i.e., discussed about
      partial-commits; we were not sure how well partial-commits are
defined nor
      interoperable though.)
      4. The screen position of the caret does not change (i.e., inserting
      empty div and moving into it will not move.)
      5. 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.

/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
>