W3C home > Mailing lists > Public > www-svg@w3.org > May 2006

Re: SVGT 1.2: no way to traverse children of non-SVG elements

From: Andrew Shellshear <Andrew.Shellshear@research.canon.com.au>
Date: Mon, 08 May 2006 10:23:15 +0200
Message-ID: <445EFFF3.9000904@research.canon.com.au>
To: www-svg@w3.org
CC: mjs@apple.com

Maciej Stachowiak wrote:
> Because the uDOM Element interface does not include firstChild,  
> lastChild, nextSibling and previousSibling, and because the  
> ElementTraversal interface is only implemented by SVGElement, the  
> uDOM does not provide a way to traverse the children of non-SVG  
> elements. This seems like a major limitation.
> 
> The ElementTraversal interface duplicates these four properties, with  
> apparently the main purpose of avoiding exposure of Text nodes. This  
> too is problematic since this interface is useless in a full DOM  
> implementation.
> 
> I see the following possibilities:
> 
> 1) Leave things alone, and allow the uDOM to contain subtrees that  
> cannot be traversed using its API.
> 
> 2) Add ElementTraversal to the Element interface, not just SVGElement.

We have agreed to do this.  It is a minimal change to the specification,
and is easy to implement.

> 
> 3) Add previousSibling/nextSibling to the Nodeinterface , and  
> firstChild/lastChild to the Element interface (not necessarily to  
> Node or Document, however). Make non-element nodes present only the  
> Node interface.
> 
> 4) Add previousSibling/nextSibling to the Nodeinterface , and  
> firstChild/lastChild to the Element interface (not necessarily to  
> Node or Document, however). Make non-element nodes present only the  
> Node interface, except for Text nodes which also present some minimal  
> Text interface (this would allow removal of alternate ways to get  
> text contents).

Options 3 and 4 are problematic for us - these represent a step 
towards full DOM functionality that we don't want to take - it adds
nodes that have to be kept in memory (all the text nodes).

> 
> I would say #1 is untenable, it seems wrong to make some subtrees of  
> the uDOM non-traversible.

True.

> I think #2 is problematic, as it would add four near-duplicate  
> attributes to a core interface.

This is somewhat irritating, true, but I don't think it's a 
show-stopper.

Thank you for your thorough review.  Please let us know shortly if  
this does not address your concerns.

Andrew.
Received on Monday, 8 May 2006 08:23:28 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:34 GMT