Re: 2 Proposals for Minimum Viable InputEvent

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</span>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