Re: before/after editaction

On Thu, Oct 20, 2011 at 7:02 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:

> On Thu, Oct 20, 2011 at 6:57 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:
>
>> I don't think we can make such an assumption. People mutate DOM on input
>> event all the time:
>> http://codesearch.google.com/#search/&q=%20oninput=&type=cs
>>
>> Including any DOM mutations in the on-going transaction would mean that
>> UA will end up trying to revert those changes since the entire document
>> shares the one undo scope by default, and may end up mutation DOM in
>> unexpected ways.
>>
>
> I'll add that, most significantly, when reverting DOM changes made in the
> input event listener fails, the UA may end up aborting the undo/redo
> process before even get to revert the actual DOM changes made by the user
> editing action or execCommand.
>

I do think sites will do that, but I expect that in practice the DOM
changes they are making are related to whatever the input was and will undo
fine.

Having just beforeInput/input will be better than having
input/beforeeditaction/aftereditaction (and possibly still beforeInput). We
should strive for that end result if we can achieve it.

It makes the input event more useful in ways that meet more use-cases than
just aftereditaction. At the same time it avoids growing the platform
unnecessarily with more events to make sense of.

Received on Thursday, 5 January 2012 03:35:33 UTC