418183 - Implement .children

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[John Resig]

The DOM Element property, .children as implemented by Internet Explorer 6+, Safari 3 (at least), and Opera 9 (at least). This property represents a NodeSet containing all the child DOM Elements of the parent element. This differs from .childNodes in that it does not include any text nodes.

By implementing this feature tangible speed gains would be able to be achieved in implementations of DOM Selector libraries (amongst other places) and as such, I'm marking this bug as being a performance improvement.

I'll be happy to provide test cases for this bug, as well, once I have a spare moment.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Is the .children documented somewhere?

W3C working draft http://www.w3.org/TR/ElementTraversal/ has other attributes
for element handling.

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

W3C are probably going to come out with a feature .childElements that is *just* a NodeList of all child elements. The problem with IEs .children is that it has a lot more features and so if we implement that we'd probably want to implement all of .children in order to avoid compatibility problems.

Comment 3

[John Resig]

(In reply to comment #2)
> so if we implement that we'd probably want to implement
> all of .children in order to avoid compatibility problems.

I don't think that'll be a problem. We implemented .all in the past and .children is significantly simpler than that (no multiple IDs make an array gotchas) - nor do we particularly have to worry about people mistakenly using this as a means of browser detection. Right now IE, Opera, and Safari all support .children as-is which is already improving the speed of JavaScript libraries that use it.

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

We certainly can implement all of .children. However it might make more sense to implement something like .childElements. For example document.all is significantly slower than getElementById due to some quirks in how it works. It even cases mutations to the DOM to be slower. I'm worried this would be even more the case with .children since there are many more .children objects than document.all objects.

I'm not concerned that people use it for browser detection, rather that people do stuff like:

if (e.children) {
  e2 = e.children.someFeature;
}
else {
  e2 = <implement 'someFeature' using normal DOM methods>
}

This currently works fine as long as we don't implement .children at all, or implement it fully. But doesn't if we just implement some parts of .children.

Comment 5

[Johnny Stenback (:jst)]

Not wanted until there's more clear info on exactly how this works in IE.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

We'll do this as part of implementing ElementTraversal. Seems like safari implements just a NodeList without the extra cruft that IE has.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This is fixed as part of bug 447917. IE further implements node.children.p as a way of getting a nodelist of all elements with the name 'p'. We don't currently do this, if someone thinks we should please file a separate bug.

Comment 8

[Joshua Mitchell (Inactive)]

Issue is Resolved - removing QA-Wanted Keywords - QA-Wanted query clean-up task