Re: Proposed errata for DOM2 Range regarding insertNode()

Chaals, please see the end of this message.

On Wed, 28 May 2008, Jonas Sicking wrote:
> > 
> > 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).
> 
> Everyone who? And based on what? I don't see anything in the spec that 
> suggests that. And as Olli pointed out there is clearly language in the 
> spec that indicates that the inserted node would be after the range in 
> the collapsed case.

Well, everyone except you and Olli apparently. :-)

Do you really think that it was intended for insertNode() to act 
differently when the range was collapsed than when the range wasn't 
collapsed, with respect to whether the inserted node ends up in the range 
or not?


> I guess I'm fine with making the change to the spec, but it would be a 
> change and not an errata.

I'm not sure what the distinction is.


> And if we're making changes anyway, I would requests that we make 
> NodeIterators behave like TreeWalkers as far as the returnvalue for the 
> NodeFilter goes. That is both more useful and easier to implement since 
> it allows more code reuse.

I recommend putting this forward as a separate errata. I only suggested 
this one because implementations seem to be differing on how to implement 
that part of the spec, and it seemed like it would be worth having a cycle 
that didn't require finding an editor to resolve the problem.

On the long term I do think we need to get Traversal Range rewritten with 
strict conformance requirements in mind.


On Thu, 29 May 2008, Olli Pettay wrote:
> 
> 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.

This seems like a consistency that would hurt the authors, though. What's 
the use case for insertNode() inserting after the range?


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

Indeed.


I do think that the spec intended the behaviour that I am proposing we 
clarify in errata, though I agree that it could be read otherwise. I 
honestly don't see any reason for the behaviour you advocate, it seems 
confusing, not useful, and not in line with the intent of the spec.

However, I'm not sure how to make further progress if you disagree to this 
change. It would be helpful if we could get a working group decision on 
this so that I could know whether the Acid3 test should be changed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 6 June 2008 17:50:19 UTC