Re: Going back to contenteditable=events

On Tue, Oct 27, 2015 at 8:16 AM, Ryosuke Niwa <rniwa@apple.com> wrote:

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

Ok, so the selection cannot be changed?

Does this also mean that it will only underline new text that is close to
the caret, or will it underline all inserted text?


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

The compositionstart event is triggered before any content is inserted into
the DOM by the browser, right? So if there is some code in JavaScript to
add some text to the DOM at compositionstart, will that text be underlined?


>
> > 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.
> of the word and surrounding content into a newly created Shadow DOM element
>


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

Noone wants to create a JS editor that doesn't work for the end user. But
how exactly the editor works may be following a logic not immediately
obvious to the browser. So the case I tried to outline above:

1. user clicks on word in Android.

2. compositionstart event is triggered. JavaScript moves a copy of the word
and surrounding content into the Shadow DOM and moves the caret there to do
everything there to keep the entire IME composition atomic.

3. At this stage the word that the user sees will not be underlined by the
browser, at least not automatically, because the browser doesn't quite
understand what is going on. But of course the JS can simply put a span
around it and then style it to underline it and thereby hte problem
disappears.



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

By "authors" you mean JS developers or text authors?

Remember that JS developers can screw up every other aspect of the editor.
We can underline when the user intends to make things bold. We can enter an
"n" when user means to type "m". We can make so that if the user types "t"
that letter, and that letter only, is entirely ignored. We can randomly add
commas to the text while the user is typing or when he/she is taking a
break.





> - R. Niwa
>
>


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