W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2011

Re: [DOMCore] Traversal

From: Anne van Kesteren <annevk@opera.com>
Date: Fri, 29 Jul 2011 17:05:24 -0700
To: www-dom@w3.org, "David Flanagan" <dflanagan@mozilla.com>
Message-ID: <op.vzenvaoa64w2qv@42-2-187-074.static.netvigator.com>
On Fri, 29 Jul 2011 16:47:18 -0700, David Flanagan <dflanagan@mozilla.com>  
> 1) I found that I was unable to make sense of the algorithms without  
> refering to  
> http://www.w3.org/TR/DOM-Level-2-Traversal-Range/traversal.html  ยง1.1 of  
> the old Traversal spec actually seems quite good, at least to my casual  
> reading.  Would you consider adding it to DOMCore as a non-normative  
> overview at the beginning of the section? Without the overview, it is  
> hard to figure out the difference between FILTER_REJECT and FILTER_SKIP,  
> for example, and it is similarly hard to understand the point of  
> pointerBeforeReferenceNode too.

Yeah, we should write introductory text at some point. Not just for this  

> 2) Is the goal of this section to simply describe and standardize  
> current implementations or to upgrade the functionality of these APIs?


> (Why, for example, did you add referenceNode and  
> pointerBeforeReferenceNode to the NodeIterator API?)

Both Gecko and WebKit exposed these.

> If the goal is to improve the Traversal APIs, how about adding  
> constructors for NodeFilter and TreeWalker?

The goal was merely to document them for now. We can add enhancements of  
course if implementors are interested in them.

> And if you do that, how about adding referenceNode and  
> pointerBeforeReferenceNode arguments to the NodeFilter() constructor and  
> a currentNode argument to the TreeWalker constructor.  Without those  
> arguments, there is no way to clone the current state of a NodeFilter or  
> TreeWalker without starting again at the root and iterating to the  
> desired position.

Why would you want to clone it?

> 3) The referenceNode/pointerBeforeReferenceNode pair seems like a  
> complicated and ugly way to represent the state of a NodeFilter.  Is  
> there any way to do better?  Could you at least change "pointer" to  
> "cursor"?  Or, what if the state was instead represented by a pair of  
> next and previous attributes, each of which was a Node or null?  These  
> would be two adjacent nodes and the cursor position would be between  
> them.  nextNode() would always return the next attribute and  
> previousNode() would always return the previous attribute, but the  
> methods would then adjust the cursor position. This would also give  
> developers an option to peek at the next or previous node without moving  
> the cursor.  I haven't tried to work the algorithms using next and  
> previous as the state variables, but it I think that a next/previous  
> pair carries the same information as  
> referenceNode/pointerBeforeReferenceNode.  And my intuition tells me  
> that the algorithms would be simpler when defined in terms of  
> next/previous.

Interesting idea. I am not sure if we can change the API additions at this  
point though.

Anne van Kesteren
Received on Saturday, 30 July 2011 00:06:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:17 UTC