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
