- From: Anne van Kesteren <annevk@opera.com>
- Date: Mon, 01 Aug 2011 14:21:20 +0200
- To: www-dom@w3.org, "David Flanagan" <dflanagan@mozilla.com>
On Sat, 30 Jul 2011 02:05:24 +0200, Anne van Kesteren <annevk@opera.com> wrote: > On Fri, 29 Jul 2011 16:47:18 -0700, David Flanagan > <dflanagan@mozilla.com> wrote: >> 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. I thought about this some more and I do not think this makes sense anymore. You cannot know the next node without running the filter algorithm and you do not want to run that until you actually want to get the next node. Well, unless you want to change the semantics of the original NodeIterator object but that seems like a bad idea. -- Anne van Kesteren http://annevankesteren.nl/
Received on Monday, 1 August 2011 12:21:53 UTC