[whatwg] DOM Range: redefining behavior under DOM mutation

[Ryosuke Niwa]

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