Re: Going back to contenteditable=events

> On Oct 25, 2015, at 5:31 PM, Johannes Wilm <johannes@fiduswriter.org> wrote:
> 
> 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. .

 Correct.

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

Right. But the browser may also decide to cancel/end composition at that point.

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

I'm not sure. The browser may decided to cancel/end composition at that point.

> 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).

Possibly.

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

No, for the purpose of underlining, the Web app needs to keep the selection/caret at where the text is inserted at all times.

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

I think we need to support some element boundaries in order to support manual justification of text.

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

What do you mean by that?

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

In the case of recomposition, the recomposed text needs to be underlined.  Basically, everything IME sees need to be underlined or else only thing the browser can do is to end/cancel the composition.

So it's extremely important for Web apps to respect what browser (and ultimately user) told them to do.  Otherwise, users are gonna have a terrible UX.

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

I definitely don't want to give authors ability to control whether underline is shown or not.  That's simply too confusing for users.

- R. Niwa

Received on Monday, 26 October 2015 23:16:46 UTC