Re: Going back to contenteditable=events

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