[whatwg] DOM Range: redefining behavior under DOM mutation

[Aryeh Gregor]

On Tue, Mar 29, 2011 at 2:37 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> In theory, yes.  In practice, you have to cover various edge cases (like
> what happens if the result of the insertBefore call is that the node is
> removed from the old location but NOT inserted at the new one); specifying
> this properly could get pretty hairy.

I don't think it would be all that bad.  But it does dampen my enthusiasm a bit.

> That sums up the situation, yes....

So is anyone planning on actually trying to remove DOM mutation events, or not?

> 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.

On Tue, Mar 29, 2011 at 2:43 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> Note that technically that behavior is a violation of DOM2 Range, but that's
> what we're trying to replace, right?

DOM 2 Range doesn't specify this, as far as I can tell.  It speaks
only in terms of "insertions" and "deletions" without explaining how
those map to actual methods.  So you could argue that insertData()
corresponds to an insertion into the text node, deleteData() to
deletion, and so on, in which case browsers all follow the spec.  And
you could argue that setting the data attribute directly corresponds
to deleting all the characters following by inserting a bunch more, in
which case browsers also follow the spec.  Except that WebKit instead
treats it inserting and deleting nothing in the special case where the
new data is equal to the old, which is also arguably a valid
interpretation of the spec.  Except that WebKit only does this for
CharacterData and not ProcessingInstructions, which would have to be a
pretty contorted reading of the spec.

But yeah, that's what we're trying to replace.