- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 1 Apr 2008 22:42:56 +0300
- To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Cc: "Web APIs WG (public)" <public-webapi@w3.org>
On Apr 1, 2008, at 18:41, Daniel Glazman wrote: > Henri Sivonen wrote: > >> How often do people pick a single child by index (with a number >> know a priori) instead of iterating over children and testing each >> one for an interesting trait? > > Let me turn the problem differently : NodeList and NamedNodeMap are > the > normal answers when we query a list of nodes, for instance through > Document.getElementsByTagName() or Element.childNodes, why should this > behave differently and why should the DOM be inconsistent here ? I prefer iterating with nextSibling null check over iterating with indexed childNodes. The childNodes feature seems to have caused a lot of complexity in DOM implementations--and for little benefit considering that the normal case is forward iteration over children. For getElementsByTagName returning a list makes sense. However, I think that live lists are a design bug in the DOM. They cause even more trouble in the getElementsByTagName case than in the childNodes case. Of course, these design decisions cannot be undone at this point, but I don't see why they should be perpetuated in the name of consistency. The Selectors API, for example, returns comatose NodeLists (list dead; nodes pointed to live), which is much better that trying to make those lists live. childElements would be a filtered list, so making it live for consistency would presumably be a bit more troublesome than keeping childNodes live. Making it comatose would be bad for perf if it is used a lot, though, since each call would instantiate a new comatose list. Moreover, the common implementation pattern is that an Element object itself is the NodeList returned by childNodes, so the same implementation pattern couldn't be used for childElements since the NodeList methods are already taken for the other purpose. > I must add that XPath also allows to select the nth child of a given > element, that Selectors can do the same through > |#myParent > :nth-child(n)|. > > Apparently querying the nth element child of an element is NOT that > uncommon: > > http://www.mail-archive.com/discuss@jquery.com/msg20124.html This talks about first vs. rest. First and last are already special compared to, say, fifth. > http://groups.google.com/group/jquery-en/browse_thread/thread/f49c09bb901f7aa6 This is about every nth, which could be implemented as a forward- iteration pass and is anyway different to just getting nth once. > http://tinyurl.com/2wsxlc > http://www.xml.com/pub/a/2007/01/24/whats-new-in-prototype-15.html?page=4 These aren't use cases. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Tuesday, 1 April 2008 19:43:45 UTC