Status

()

Core
DOM
RESOLVED FIXED
9 years ago
3 years ago

People

(Reporter: John Resig, Unassigned)

Tracking

({perf})

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.1 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

9 years ago
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

9 years ago
Is the .children documented somewhere?

W3C working draft http://www.w3.org/TR/ElementTraversal/ has other attributes
for element handling.
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.
(Reporter)

Updated

9 years ago
Blocks: 265455
(Reporter)

Comment 3

9 years ago
(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.
Flags: wanted1.9.1?
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.
Not wanted until there's more clear info on exactly how this works in IE.
Flags: wanted1.9.1? → wanted1.9.1-
We'll do this as part of implementing ElementTraversal. Seems like safari implements just a NodeList without the extra cruft that IE has.
Depends on: 447917
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.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Issue is Resolved - removing QA-Wanted Keywords - QA-Wanted query clean-up task
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.