[whatwg] DOM Range: redefining behavior under DOM mutation

Ryosuke Niwa rniwa at webkit.org
Sun Apr 3 04:54:09 PDT 2011

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

More information about the whatwg mailing list