- From: Ryosuke Niwa <rniwa@webkit.org>
- Date: Sun, 3 Apr 2011 14:54:09 +0300
Sorry for the delayed response. On Tue, Mar 29, 2011 at 11:53 PM, Aryeh Gregor <Simetrical+w3c at gmail.com>wrote: > > That sums up the situation, yes.... > > So is anyone planning on actually trying to remove DOM mutation events, or > not? > We would love to. We've already made DOM mutation events asynchronous during editing commands and adoptNode. > That's actually a really hard question to answer, due to the command > > dispatch setup used (which has tons of indirection). ;) Which command > are > > you thinking here? > > Just something simple like running execCommand("bold") when "bar" is > selected in fairly trivial markup like > > <p><b>Foo</b>bar</p> > > The result will be that "bar" is still selected but now wrapped in the > same <b> as "Foo", which isn't the result you'd get using any sequence > of JavaScript-visible DOM method calls I can think of. For WebKit, we fix selection as we modify DOM. When things get really complicated, we save Range as the visible position index at the beginning of a command, and restore the Range later using that index because most of commands don't add/remove text. On Wed, Mar 30, 2011 at 2:48 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > On 3/29/11 5:53 PM, Aryeh Gregor wrote: > >> So is anyone planning on actually trying to remove DOM mutation events, or >> not? >> > > I think Jonas is still planning on it; we just need to implement a > replacement for them first... It's my understanding that implementing input/beforeinput events will address most use cases of mutation events at least for editing purposes. - Ryosuke
Received on Sunday, 3 April 2011 04:54:09 UTC