[whatwg] DOM Range: redefining behavior under DOM mutation

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.

Hmm, wait a sec.  I just reviewed the spec for insertBefore(), and I
don't see any way this could happen.  If anything would prevent it
from completing successfully, an exception is supposed to be thrown
before anything else is done.  Under what conditions could it be
removed from the old parent but not added to the new parent?

On Tue, Mar 29, 2011 at 8:48 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> I haven't looked up the details of how we implement this (because it really
> is a huge pain; let me know if you want me to do that)

No, it's not necessary.  I'll wind up speccing whatever seems like the
best way to do it, subject to implementer feedback.  This will involve
however much reverse-engineering as necessary.  It would be useful to
have a basic idea in advance of how at least one implementation
actually does it, because it might reveal issues I hadn't thought of,
but it's not necessary.

> but the behavior you
> describe is the result of doing this:
>
> ?var range = getSelectionRange(); /* However you implement this */
> ?var b = document.createElement("b");
> ?range.surroundContents(b);
>
> The range is explicitly repositioned by the end of the surroundContents
> algorithm.

That would result in

  <p><b>Foo</b><b>bar</b></p>

but actually, the result in Gecko is

  <p><b>Foobar</b></p>

reusing the existing <b> element.  surroundContents() doesn't work
here, because in all browsers except Opera it removes all children of
the node before appending the range's contents.  (Opera actually
follows DOM 2 Range here, but other browsers don't.)

More generally, this approach doesn't help you if you need to do
different things for different parts of the selection.  Like if you
had

  <p><b>Foo</b>[bar<b>baz</b>quz]</p>

and the user bolded the selection, I don't see any conceivable
Range-based manipulations that would preserve the selection while
giving the actual result, which is

  <p><b>Foo[barbazquz]</b></p>

So browsers must be special-casing how execCommand() affects
selections somehow, which is sad.

Received on Wednesday, 30 March 2011 10:50:05 UTC