Re: Proposed errata for DOM2 Range regarding insertNode()

Ian Hickson wrote:
> On Fri, 23 May 2008, Olli Pettay wrote:
>> So I'm not sure the errata for this issue is actually needed.
> 
> It seems to me that everyone agrees that insertNode() was always intended
> to insert a node _into_ the range, and that the collapsed case was simply
> lost between the cracks when the DOM WG was writing the spec (much as was
> interaction with mutation events, for instance). While I agree that the
> spec could be read as saying that the node is inserted after the range
> when it is collapsed, I don't think we want that behaviour, nor that it
> was intended. Do you actually think that behaviour is preferred to the
> insertion behaviour?

The current version of the spec handles dom mutations consistently
(whether using node.insertBefore/appendChild or range.insertNode)
and that is not something I'd like to lose.

If that is changed, the insertNode part of the following wouldn't be
true anymore (2.12):
"Any mutation of the document tree which affect Ranges can be considered 
to be a combination of basic deletion and insertion operations. In fact, 
it can be convenient to think of those operations as being accomplished 
using the deleteContents() and insertNode() Range methods and, in the 
case of Text mutations, the splitText() and normalize() methods."


Let's have a testcase [1]:
<root><element1/><element2/></root>
and collapsed range is between element1 and element2.

element3 is inserted using the current version of insertNode():
<root><element1/><element3/><element2/></root>
Range stays collapsed and is pointed right after element1.

If element3 is inserted using root.insertBefore(element3, element2):
<root><element1/><element3/><element2/></root>
Range stays collapsed and is pointed right after element1, so the same
as with insertNode().

Now, if insertNode starts to work differently when range is collapsed 
the result would be:
<root><element1/><element3/><element2/></root>, but range wouldn't be 
collapsed anymore, instead start boundary point would be after element1
and end boundary point after element3. And this means that mutation 
can't be thought "of ...as being accomplished using ... insertNode()
Range method..."
Or is there some combination of insertNode()s and deleteContents()s
which would lead to the collapsed range after <element1/>?


FF2, FF3, Opera9.2x and Opera9.5b have the, IMO, correct behavior,
Safari3.1 doesn't nor does ACID3'ed-Opera[2]


-Olli

[1] http://mozilla.pettay.fi/moztests/range_test.xhtml
[2] http://labs.opera.com/news/2008/03/28/

Received on Wednesday, 28 May 2008 21:58:58 UTC