W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: before/after editaction

From: Ojan Vafai <ojan@chromium.org>
Date: Wed, 4 Jan 2012 19:34:45 -0800
Message-ID: <CANMdWTsuEWuRK9bYbEWO5JhyESrX59BEnuxjGA4FRd04B3nKRw@mail.gmail.com>
To: Ryosuke Niwa <rniwa@webkit.org>
Cc: Jonas Sicking <jonas@sicking.cc>, Darin Adler <darin@apple.com>, public-webapps <public-webapps@w3.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT