Re: Going back to contenteditable=events

On Sun, Oct 25, 2015 at 7:04 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
...

> 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 all sounds very good! Just to make sure I understand your proposal
correctly:

1. Any addition to text nodes in the DOM part that makes out the editor
that is caused by JS functions called through listeners to the
corresponding beforeInput events will be underlined automatically by the
browser until compositionend. Other changes to the DOM, caused by other
pieces of JS that happen during the period of time that the composition
takes places, will not be underlined. For JS developer, this will be
similar to how only "user initiated" javascript is allowed to add things to
the clipboard, etc. .

2.  If the JS decides not to add a specific character to a text node, then
the browser is ok with that and will simply not underline anything extra.

3. If the JS decides to add one or several different character to a text
node than the character the IME thinks should be there, the browser will
not worry about that and underline the character(s) that the JS added.

4. There is no distinction between DOM and Shadow DOM as far as finding
added characters to text nodes. As long as the addition happens in either a
Shadow DOM hosted within the editor part of the DOM or the editor part of
the DOM itself, it will be underlined (If it's visible).

5. All necessary information about the selection and it's placement in
relation to words before/after, etc. are taken at the time the composition
is initiated. If the selection is changed later on during the composition,
that's OK and the composition will continue as if the caret was where it
was during initiation.

Correct? (Not that I can see any concrete use for 2 or 3)

If the answer is yes to those, I think I have understood.

As far as I can tell, this should solve everything for IMEs that only
compose and don't recompose.


For recomposition, as far as I can tell, the most interesting piece of
information at compositionstart would be the range that makes out the word
that is to be edited. (I stated this before, but just to make sure that
this is also interesting here).


Two things I wonder about:

1. When doing recomposition,, and the word that is being edited goes across
several DOm elements, the IME will likely request to unite the word in a
single DOM element (as it does now). What happens if the JS decides not to
do that? Can the browser still udnerlien the entire word (that will be
spreading across DOm nodes)


2. The other thing I wonder is what should happen to DOM changes at
compositionstart (iow: before a single character has been added): Should
they be underlined or not?


An argument against underlining:

Use case A: A collaborative editor where the editor doesn't want to share
partially constructed characters with collaborators. To make that easier,
it isolates the construction of characters in a Shadow DOM. For that
purpose, it copies the entire text nodes that construction will happen in +
it's siblings into the Shadow DOM at compositionstart. A new word is to be
constructed, the other contents that are to be copied should not be
underlined.

An argument for underlining some things:

Use case B: Similar to previous use case, but an existing word is to bee
recomposed. Everything is copied and shouldn't be underlined -- except the
word that is to be recomposed.



I think it would be fine if we just take care of use case A. We can simply
do manual underlining if this is needed for usecase B.


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