Re: 2 Proposals for Minimum Viable InputEvent

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.