[whatwg] DOM Range: redefining behavior under DOM mutation

[Boris Zbarsky]

On 3/29/11 2:19 PM, Aryeh Gregor wrote:
> It would be possible to work around it by requiring that
> insertBefore() and similar methods do special magic for Ranges
> independent of the actual DOM mutations done, however.

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.

> That already has to happen for
> insertData()/deleteData()/appendData(), right?  All browsers treat
> those differently from just setting the data to the equivalent
> string.

Those map directly to atomic operations on CharacterData, for what it's
worth.

>> Now if we dropped support for mutation events and userdata
>> handlers first.....
>
> Is that feasible?  I get the impression implementers would all love
> it, but somehow they haven't done it yet.

That sums up the situation, yes....

> DOM Core says it's supposed to be basically
>
> if (B.ownerDocument != A.ownerDocument) {
> A.ownerDocument.adoptNode(B); }
>
> // Insert into the children
> <http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-node-insertbefore>

Ah, that's new.  That matches what Gecko does, yes.

> When I thoughtlessly
> mutated the DOM from the event handler, though, I definitely hit a
> lack of interop.

Verily.

> Anyway, then what does Gecko do for execCommand()?

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?

-Boris