Re: [DOMCore] Traversal

On Fri, 29 Jul 2011 16:47:18 -0700, David Flanagan <dflanagan@mozilla.com>  
wrote:
> 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  
feature.


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

Yes.


> (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
http://annevankesteren.nl/

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