W3C home > Mailing lists > Public > www-svg@w3.org > February 2005

Re: getElementById method on SVGSVGElement

From: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
Date: Sat, 05 Feb 2005 19:30:30 -0500
Message-ID: <42056526.2020204@Kodak.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: Robin Berjon <robin.berjon@expway.fr>, www-svg@w3.org

> Thomas DeWeese wrote:

>>    Then do it in a version of the spec that doesn't try to be
>> "upward compatible".  BTW when I looked at the implementation in
>> Batik I noticed a feature of this method, it allows for
>> searching of disconnected subtrees (which could have duplicate
>> id's, since they aren't in the document).

Boris Zbarsky wrote:

> How is one to reconcile that feature with restrictions on duplicate IDs 
> when the node _is_ in the document?  Please suggest reasonable wording?

    Well, it would seem to me that the restriction is that duplicate
id's are not allowed on any two Elements that can be reached via
the DOM tree traversal methods (getParentNode, firstChild, 
nextSibling, etc).  If the node is in the document then all of it's
nodes are reachable from all other nodes in the document and thus
the id's in the SVG element's subtree must not duplicate any in the
rest of the document tree.  I don't think this part is any different
from the behavior of any existing conforming DOM implementation.
The only real differences are that you can search the disconnected
pieces, and that you probably shouldn't have duplicate id's in
such disconnected pieces (which I think is allowed by core DOM).

    Take for example the following pseudo code:

	var x = document.createElement("a");
	x.appendChild(document.createText("New Text");
	x.setAttribute("id", "foo");
	var y= document.getElementById("foo")
	y.parentNode.replaceChild(y, x)

    Certainly you don't suggest that this is a problem.

    Now if we change the last line to:


    Then there is a problem, but all the above is just core DOM.
Perhaps I missed the point of the question?

> Note that the definition of the method explicitly talks about the 
> "document tree", so it's not clear to me whether Batik's behavior is 
> even correct...  If it is, the method's definition in the specification 
> needs a _lot_ of clarification.

    Well first, please don't take things out of context, the full
sentence from the specification is:

    	Searches this SVG document fragment (i.e., the search is
	restricted to a subset of the document tree) for an Element
	whose id is given by elementId.

    First note the use of the term 'document fragment' this is the
name of the DOM object for a disconnected collection of Nodes,
where as the mention of the document tree is in a parenthetical
statement (and at that I'm not sure that such an independent
set of nodes couldn't loosely be called a document tree - although
admittedly that would be a little stretch).
Received on Sunday, 6 February 2005 00:30:33 UTC

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