- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 02 Apr 2008 00:15:21 -0700
- To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Cc: "Web APIs WG (public)" <public-webapi@w3.org>
Daniel Glazman wrote: > >> I'm actually not sure. How often do authors want to get the third >> child without knowing anything more about it than that it's an >> element? Iterating through the kids (by means of ET or '.childNodes') >> gives you much more context information (what type of element it is, >> what it's bbox is, whether or not it has text/child content, etc.). >> Not trying to be a pain, but can you identify a concrete use case? > > [admin: please Cc me, I am not following this mailing-list] > > I probably has to use it in my daily code - find the n-th child element > of another given element - at least a dozen times in the last fifteen > days. Iterating through the kids is a for my point of view pure bloat > compared to myFooElement.childElements.item(3)... I agree with Daniel, while I don't write a lot of javascript myself I've seen a number of cases like this in the javascript used to implement firefox: bar = foo.parentNode.parentNode.childNodes.item(3).firstChild; Basically I wonder why we wouldn't give access to items by index? Complexity of implementation really can't be an argument here, the amount of code to implement this is trivial, especially compared to all other things required by a browser or DOM implementation. Like Boris pointed out it's likely that an implementation could reuse existing code, but even if that isn't the case I would imagine that the code to implement this property is laughable compared to the code needed to draw an antialiased spline or implementing DOM events (part of which I use as a hiring interview question due to its complexity). I remember in the initial releases of gecko we got a lot of support questions from people wondering why their DOM-using code didn't work in Netscape when it worked in IE. The reason was that IE didn't create DOM nodes for whitespace-only nodes and so the DOM was significantly different and harder to figure out where your nodes lived. getElementById helped to some extent here, and I think that recent development of javascript libraries has helped a lot too. However if we are arguing that people should use those solutions there really is no need for the ElementTraversal spec at all. So I honestly can't understand the complexity argument at all. I think ElementTraversal is something that users really want and would be trivial to implement with or without .childElements. So there really is no need to cut corners and good arguments not to. / Jonas
Received on Wednesday, 2 April 2008 07:16:30 UTC