Re: Going back to contenteditable=events

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.


>
>    - 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.
>
>
So not at compositionend? We would need that as well.


>
>    1.
>       2. 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?


>
>    1.
>       2. The screen position of the caret does not change (i.e.,
>       inserting empty div and moving into it will not move.)
>       3. 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