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