W3C home > Mailing lists > Public > www-svg@w3.org > January 2010

Re: removeChild and <use> question

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 12 Jan 2010 16:28:33 -0500
Message-ID: <4B4CE981.5070905@mit.edu>
To: Jeff Schiller <codedread@gmail.com>
CC: "www-svg@w3.org" <www-svg@w3.org>
On 1/12/10 4:08 PM, Jeff Schiller wrote:
> Personally I find it surprising that Firefox and Opera do this.
> removeChild() is a DOM Level 2 method and it seems like there
> shouldn't be any side-effects for removing a child other than...
> removing the child :)

That's not quite true.  In an ideal world, in my opinion, there should 
be no hysteresis in the DOM.  That is, after removing the child the 
state of the document should be as if that child had never existed, as 
much as possible.

This is not really possible with <script>, but things like <html:style> 
nodes (or heck, xml-stylesheet PIs) will make the stylesheet not apply 
anymore upon removal.  All node removals cause relayout in the CSS 
renderer to take into account that the CSS boxes for the removed node 
are no longer there.  Removing a node changes the values returned by 
various DOM APIs, changes the internal state of various DOM objects 
(e.g. live nodelists), can change the base URI of the document (if the 
node is an <html:base>), can change the title showing up in the 
browser's titlebar, and so forth.

> It seems like in Opera/Firefox, the following code:
>      var someUsePointingToFoo = ...;
>      g.removeChild(foo);
> would result in someUsePointingToFoo still holding a reference to a
> <use>  element, but it is now detached from the DOM

Not at all.  It's in the DOM just fine.  However its cloned instance 
tree is now gone.  It's the same as if you had a <use xlink:href="#foo"> 
and had no node with id="foo" in the document.

> I also can see why
> UAs decided to do this, since otherwise it would leave the document in
> some sort of error state.

The document just ends up in an "error state", yes (with the <use> 
therefore not being rendered).  I don't see the problem there...

> Seems like this problem is unique to SVG since HTML doesn't have such concepts.

Sure it does.  For example, <html:img usemap="#foo">.  Removing the 
relevant <map> from the DOM should make the image no longer have an 

Received on Tuesday, 12 January 2010 21:29:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:19 UTC