W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: Proposed errata for DOM2 Range regarding insertNode()

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Wed, 03 Sep 2008 20:51:27 +0300
Message-ID: <48BECE9F.4060504@helsinki.fi>
To: Web Applications Working Group WG <public-webapps@w3.org>

Ian Hickson wrote:
> DOM2 Traversal and Range has a number of problems, and really needs a
> rewrite. However, in the absence of the resources to do that, I realised
> that we could settle for releasing some errata. Arguably we as a working
> group have somewhat the authority to do that, so here's a proposal for a
> simple errata for DOM2 Range. If this works process out well, I'll see if
> there are other things in DOM2 we should errata sooner rather than waiting
> for wholesale DOM3 or DOM4 updates.
> DOM2 Range says of the insertNode() method that "A node may be inserted
> into a Range using the following method". However, if the range is
> collapsed, according to a strict reading of the specification, calling
> insertNode() actually inserts the node _after_ the range. I propose that
> we change the spec to explicitly say that if you call insertNode() on a
> collapsed range, the end point offset is increased by one, as if the node
> was inserted before the end point, which I believe to be the intent of the
> specification. This is implemented by Opera and WebKit already, and is
> tested by Acid3.

If insertNode isn't handled the same way as other mutations, we'll have to specify
whether mutation events happen before or after updating boundary points.
Otherwise there will problems like what webkit has with http://mozilla.pettay.fi/moztests/insertnode.html :
   An element is inserted to parent, then mutation event handler removes it and adds it back.
   Based on Range spec, mutating DOM the way that node is inserted to end boundary shouldn't
   change the range, so in this case range should be collapsed after mutation handler.

Even if we wanted to have some special case for mutation events here (and I really don't want), I'm not sure
it can be achieved easily since insertNode may insert many nodes using document fragment.

So I still propose that all the mutations to DOM are handled in a consistent way and
that the definition of insertNode doesn't need to be changed. It is ACID3 which requires a small change.


Received on Wednesday, 3 September 2008 17:52:02 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:11 UTC