Re: 2 Proposals for Minimum Viable InputEvent

On Wed, Feb 8, 2017 at 5:54 PM, Alexandre Elias <aelias@google.com> wrote:

> > One of the editors, ProseMirror therefore recently changed to a model
> where it would let the browser handle changes to text nodes and then
> roll-back those changes if undesired. The problem was that this lead to
> "edit flashes" [2] where the user can see the DOM changes twice rapidly.
>
> Right, my proposal you described as "babysitting Javascript" would be to
> treat such "edit flashes" as a UA bug that we could fix (provided the JS
> DOM change is completed synchronously within scope of input event, and does
> not change the plaintext distillation).  This approach would not require
> any new web platform API, it would just make the longstanding APIs work
> better for your use case.
>

Ok, I will let the developer know. Thanks for that!

>
> > The problem is that the plaintext distillation may eb slightly
> different, if for example, the JavaScript uses animated gifs for some of
> the letters
>
> I believe this use case can only be solved by the long-term "full
> model/view/controller" IME solution yosin@ and I ultimately prefer,
> whereby IME talks to an invisible textbox "model" and JS maps it to any
> DOM/canvas/WebGL.  You need 100% separation between plaintext distillation
> and user-visible representation to do things like this, and none of the
> proposals on the table address it.
>

If all the beforeinput events related to IME can be made cancellable (in
the sense that the IME assumes that the JS does all necessary DOM updates),
then this should be possible.

Or, if we keep the spec as it is now with all five beforeinput events, then
this exchange an be easily done at the moment the IME process ends.



>
> > For example, how do we handle the backspace and delete keys now? We
> listen to keydown, discover which key was pressed and with what modifiers
> and delete the content. We might not be able to implement "delete word" or
> "delete soft line" very precisely, but these are really minor issues. So,
> in this case the before input wouldn't give us anything. Actually, it'd be
> even worse than listening to the keydown event because we can cancel the
> keydown event.
>
> Acknowledged, the backspace-to-delete-line problem is quite familiar to
> me.  Note that on Android, IME typically send deleteSurroundingText(1, 0)
> IME event when soft backspace key is pressed, or even
> setComposition("hell") (if previous text was currently-being-composed
> "hello").  So some amount of JS hackery for rich backspace seems
> unavoidable, unfortunately.
>
> > The same with text formatting – we can easily listen to CTRL+B to know
> whether someone wants to bold a text.
>
> The current plan is that we will allow Ctrl-B beforeinput to be one of the
> few cancelable ones.  It never originates from any known IME so it's
> relatively easy, and there will be no other event fired for Mac OS X
> touchbar buttons for bold/italic.
>
> > However, there's one nasty case which may still require hacking if the
> event isn't cancelled. It's how the editor can delete the content itself
> when the user is typing over a non-empty selection. We can't let the
> browser do that because we wouldn't know how to convert those changes to
> the model (and sometimes it might simply be impossible).
>
> Understood.  I'm not a fan of the solutions to this issue proposed so far,
> but how about this: what if we extend "getTargetRanges()" to work on the
> "input" event (not only "beforeinput") to indicate what range of text has
> just been inserted?
>

Having this information around cold be very interesting indeed.

But I wonder whether you are suggesting for JS developers to henceforth
create editors where they have to diff and potentially roll-back all
keyboard input. We were kind of hoping one could do less of that with the
advent of the beforeinput event. Instead of doing all that, I am afraid a
lot of users will simply intercept the keydown and use that instead on
desktop and do as Piotr described on mobile and not care about the
beforeinput event at all.

As for the touchbar -- true, that is a real painpoint and that seems to be
one of the few use cases left for the beforeinput event if we are to take
in the proposals you guys are making.

Although I think much more important for the touchbar is to figure out how
to turn it off.



> That should provide the same information as the "deletion/insert" split
> option, without adding one of those "phantom" events I dislike.  Knowing
> precisely what range has just been inserted, your JS could then remove it
> from DOM, apply your deletion reconciliation algorithm, and then reinsert
> it.
>

When you talk of phantom events, you are talking about phantom events you
mean those of the five events in the IME that Android currently does not
emit, right? These events seem to be real in the Chrome desktop version. If
you fully expect the JS to roll  back u to major DOM changes with every key
that is being pressed, why is tiing so crucial when IME is to start so that
you cannot separate the two initial events? I mean some extra complexity
has to come in somewhere to make a working editor.

Also, on the desktop, deletion in most cases seem to happen outside of
compositions, also for those users who do use IMEs.

And for keyboard users, this shouldn't be a problem at all. I don't really
get why we create this problem that seems to invalidate the beforeinut
event for a so many use cases out of solidarity with mobile users, when
it's technically only an an isolated issue for mobile users who often won't
have as much of a richtext interface anyway (just look at the mobile html
version of Gmail). And even that is mainly a matter of the Android team not
wanting to add these events, not because it is technically impossible.

I can see two useful proposals in this:

* Treating edit flashes as bugs may lead to this being less of a problem.
* Adding the targetranges to the input event so that we can see where
something has happened. This could turn out to be of interest to some
editors.


But I cannot really see why we should replace the current spec, which
really solves a lot of issues as it is with a severely limited version for
which it's not clear if there is a value of having it for most  editors.


>
> --
> Alex
>
> On Wed, Feb 8, 2017 at 9:35 AM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
>
>> So maybe one could say that as long as a change is limited to only an
>> inline node, it is ok nott o be cancelabble?
>>
>> How about this for example:
>>
>> <p>a[bc<span contenteditable=false>def<span contenteditable=true>gh]i</spa
>> n>jkl</span>mno</p>
>>
>> or
>>
>> <p>ab[c<table>...<tr><td>de]f</td></tr></table>ghi</p> (is this change
>> inline or block?)
>>
>>
>> Not that these are the most common piece of html to be found in an
>> editor, but it certainly is something that could be there. I fear a little
>> bit that every time we say something like "this looks so simple, surely the
>> browser won't be able to mess that up", we'll find new edge cases where the
>> browser wasn't able to figure out what to do. And we continue to have to
>> diff it, make virtual DOMs, etc.
>>
>> The point of making input* non-cancellable seems to have been to make
>> keyboard and IME input be handled by the same JS code as if there was no
>> difference. Does that seem feasible to you, Piotr?
>>
>> On Wed, Feb 8, 2017 at 5:09 PM, Piotr Koszuliński <
>> p.koszulinski@cksource.com> wrote:
>>
>>>
>>>
>>> On Wed, Feb 8, 2017 at 4:28 PM, Johannes Wilm <johannes@fiduswriter.org>
>>> wrote:
>>>
>>>> That is very interesting. I am wondering if what you are saying is that
>>>> it is ok for beforeinput events not to be cancelable as long as they don't
>>>> affect more than a single text node and if they change anything beyond that
>>>> you really need to start diffing or using other kinds of events?
>>>>
>>>
>>>
>>> Not exactly. It's acceptable if we can't cancel events which default
>>> actions are "local". I mean, if I make such a selection:
>>>
>>> <h1>a[b</h1>
>>> <p>c]d</p>
>>>
>>> And press "x", then someone needs to delete "b" and "c", perhaps merge
>>> those two blocks and move the selection to a correct place. We want to
>>> control that behaviour, because there are couple of potential results. E.g.
>>> Chrome tends to a lot of mess with inline elements and styles when merging
>>> two blocks. We must prevent that.
>>>
>>> Currently, we prevent that by discovering the keydown event, checking
>>> that (**most likely**) it means inserting the "x" letter. So what we do
>>> now, is that we call our internal deleteContent() method which results in:
>>>
>>> <h1>a[]</h1><p>d</p>
>>>
>>> and let the browser insert "x" after "a".
>>>
>>> The situation is a bit simpler if we have a selection like:
>>>
>>> <p><b>a[b</b>c]d</p>
>>>
>>> If we wouldn't be able to call our deleteContent() method for that
>>> content because, for example, a composition takes place and if the browser
>>> would insert the composed text outside the <b> element (let's assume we
>>> want it to be inside), it's okeysh if we fix that after composition has
>>> ended. It's not perfect, but it's acceptable because the expected result
>>> isn't much different from what browser produced.
>>>
>>>
>>>
>>
>>
>>
>> --
>> Johannes Wilm
>> Fidus Writer
>> http://www.fiduswriter.org
>>
>
>


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