Re: Going back to contenteditable=events

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.

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


-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org