element.children.length v/s element.childNodes.length
okey
Are these equiv? Both attributes exist in ie6, but ff does not have
element.children.length defined
For objects in both browsers, in which element.childNodes.length
report, say 8
IE element.children.length == 8, FF element.children.length == not
defined.
Can I replace code using element.children.length with use
element.childNodes.length?
Thanks.
Conrad Lender
No. childNodes contains all node types (*), children only contains the
child element nodes. This div:
<div>text<img [...]>text2</div>
would have childNodes.length == 3 and children.length == 1.
*) IE usually ignores text nodes that only contain white space; the
standard compliant browsers don't.
- Conrad
Richard Cornford
> On 24/05/09 14:37, okey wrote:
>> Are these equiv? Both attributes exist in ie6, but ff does
>> not have element.children.length defined
>>
>> For objects in both browsers, in which
>> element.childNodes.length report, say 8
>>
>> IE element.children.length == 8, FF
>> element.children.length == not defined.
>>
>> Can I replace code using element.children.length with use
>> element.childNodes.length?
>
> No. childNodes contains all node types (*), children only contains
> the child element nodes. This div:
Historically (and so possibly currently) that has not been entirely
true. For example, IceBrowser 5 had its - children - collections refer
to the same object as its - childNode - collections, and so they would
contain all nodes and not just Element nodes. That almost certainly
represented a seriously flawed attempt to be compatible with IE browsers
without going to the effort of writing a truly compatible - children -
collection object, but it is still part of the reality that would
suggest leaving the - children - alone and concentrating on the more
predictable - childNodes - whenever available.
> <div>text<img [...]>text2</div>
>
> would have childNodes.length == 3 and children.length == 1.
>
> *) IE usually ignores text nodes that only contain white space;
Strictly that should be ' ignores text nodes that contain (what the
specs describe as) "non-significant" white space. Non-significant white
space might be, for example, a carriage return (and tabs) between the
closing and opening tags of two consecutive block elements, and be
non-significant because it would not influence the rendering of (or
reading of, or whatever of) the document.
> the standard compliant browsers don't.
Putting it like that suggests not representing the non-significant white
space in the DOM is not "standards compliant"; a fault. It is not. This
behaviour is a feature of DOM parser software (software that translates
character sequence input into DOM structure output) and the pertinent
specs for that software makes the representation of non-significant
white space optional (and so usually switchable in the software). As a
result, whenever you have no control over the configuration of the DOM
parser (as is always the case in normal web browser DOM scripting) the
expectation that can be derived from the standards is that
non-significant white space either may or may not be represented in the
resulting DOM. Meaning it is that expectation that should be programmed
into crosss-browser scripts.
Lots of people do fall foul of writing scripts with the expectation that
non-significant white space either will be represented in the DOM or
will not, but that is non-'standards compliant' behaviour on their part,
not an issue with web browsers.
Richard.
okey
> > Are these equiv? Both attributes exist in ie6, but ff does not have
> > element.children.length defined
> > Can I replace code using element.children.length with use
> > element.childNodes.length?
>
> No. childNodes contains all node types (*), children only contains the
> child element nodes. This div:
>
> <div>text<img [...]>text2</div>
>
> would have childNodes.length == 3 and children.length == 1.
> - Conrad
Thanks Conrad. I just did a dump of all the attributes in the ff
object, and it doesn't defined children at all. It does have 8
element nodes (nodeType == 1). Is 'children' a good thing to use?
And since, for whatever reason (us.. for example) ff doesn't have this
attribute we'll have modify code to allow ff users access. Thanks
again.
Martin Honnen
> Are these equiv? Both attributes exist in ie6, but ff does not have
> element.children.length defined
FF 3.5 will have a children property on element nodes:
https://developer.mozilla.org/En/DOM/Element.children
--
Martin Honnen
http://msmvps.com/blogs/martin_honnen/
David Mark
> > > Are these equiv? Both attributes exist in ie6, but ff does not have
> > > element.children.length defined
> > > Can I replace code using element.children.length with use
> > > element.childNodes.length?
>
> > No. childNodes contains all node types (*), children only contains the
> > child element nodes. This div:
>
> > <div>text<img [...]>text2</div>
>
> > would have childNodes.length == 3 and children.length == 1.
> > - Conrad
>
> Thanks Conrad. I just did a dump of all the attributes in the ff
> object, and it doesn't defined children at all. It does have 8
> element nodes (nodeType == 1). Is 'children' a good thing to use?
No.
>
> And since, for whatever reason (us.. for example) ff doesn't have this
> attribute we'll have modify code to allow ff users access.
That's why. See Richard's response.
David Mark
> okey wrote:
> > Are these equiv? Both attributes exist in ie6, but ff does not have
> > element.children.length defined
>
> FF 3.5 will have a children property on element nodes:https://developer.mozilla.org/En/DOM/Element.children
Should still be avoided, just like their document.all.
Conrad Lender
> Thanks Conrad. I just did a dump of all the attributes in the ff
> object, and it doesn't defined children at all. It does have 8
> element nodes (nodeType == 1). Is 'children' a good thing to use?
No, because it's not available on some current browsers, and even if
it's there, it isn't implemented in a consistent way - see also
Richard's excellent correction of my earlier post.
I wasn't aware of IceBrowser's botched implementation. To be honest, it
never occurred to me to test with that browser, and IceSoft don't
exactly go out of their way to provide web developers with a test
version ("ICEbrowser downloads are only available to supported
customers", "Supported customers can access downloads using their FTP
account information provided to them by ICEsoft product support").
> And since, for whatever reason (us.. for example) ff doesn't have this
> attribute we'll have modify code to allow ff users access.
The DOM2 specification doesn't define a "children" property for element
nodes, AFAICS it's a non-standard extension. As useful as it would be to
have a collection of child elements, for the time being we're stuck with
childNodes, which is well supported across browsers (*). Keep in mind
the mentioned differences in the handling of non-significant (thanks,
Richard) white space when you loop over childNodes:
<tr>
<td>...</td>
<td>...</td>
</tr>
This TR element can have five childNodes (Firefox, Safari) or two
childNodes (IE, Opera, Konqueror).
- Conrad
(*) I guess you could try using XPath for browsers without a "children"
collection, but I doubt that would be more reliable.
David Mark
> On 24/05/09 16:15, okey wrote:
>
> > Thanks Conrad. I just did a dump of all the attributes in the ff
> > object, and it doesn't defined children at all. It does have 8
> > element nodes (nodeType == 1). Is 'children' a good thing to use?
>
> No, because it's not available on some current browsers, and even if
> it's there, it isn't implemented in a consistent way - see also
> Richard's excellent correction of my earlier post.
>
> I wasn't aware of IceBrowser's botched implementation. To be honest, it
> never occurred to me to test with that browser, and IceSoft don't
> exactly go out of their way to provide web developers with a test
> version ("ICEbrowser downloads are only available to supported
> customers", "Supported customers can access downloads using their FTP
> account information provided to them by ICEsoft product support").
>
> > And since, for whatever reason (us.. for example) ff doesn't have this
> > attribute we'll have modify code to allow ff users access.
>
> The DOM2 specification doesn't define a "children" property for element
> nodes, AFAICS it's a non-standard extension.
As far as you can see?
> As useful as it would be to
> have a collection of child elements, for the time being we're stuck with
> childNodes, which is well supported across browsers (*). Keep in mind
> the mentioned differences in the handling of non-significant (thanks,
> Richard) white space when you loop over childNodes:
>
> <tr>
> <td>...</td>
> <td>...</td>
> </tr>
>
> This TR element can have five childNodes (Firefox, Safari) or two
> childNodes (IE, Opera, Konqueror).
Your pigeonholes are laughable. And you wouldn't care in this case as
you are just filtering the white space.
[snip]
> (*) I guess you could try using XPath for browsers without a "children"
> collection, but I doubt that would be more reliable.
How many browsers support neither childNodes nor children, but have
document.evaluate? Are you really suggesting eschewing the standard
childNodes property for a call to that method? Some concern about
mixing up filtered white space?
Conrad Lender
> On May 24, 12:59 pm, Conrad Lender <crlen...@yahoo.com> wrote:
>> The DOM2 specification doesn't define a "children" property for element
>> nodes, AFAICS it's a non-standard extension.
>
> As far as you can see?
Depends on what is seen as the "standard". Not so long ago, Microsoft
would have called their documentation the standard. And when most
implementations support a feature, it could be argued to be a de-facto
standard. (NB, I wasn't recommending to use .children)
>> <tr>
>> <td>...</td>
>> <td>...</td>
>> </tr>
>>
>> This TR element can have five childNodes (Firefox, Safari) or two
>> childNodes (IE, Opera, Konqueror).
>
> Your pigeonholes are laughable. And you wouldn't care in this case as
> you are just filtering the white space.
Pigeonholes, eh? Know any implementations that would find a different
number than 2 or 5 in this case? Or do you mean that I should have
mentioned more examples?
The need to filter the white space text nodes in laughable pigeonhole
number 1 is the whole point. So yes, I do care.
>> (*) I guess you could try using XPath for browsers without a "children"
>> collection, but I doubt that would be more reliable.
>
> How many browsers support neither childNodes nor children, but have
> document.evaluate?
You completely misunderstood that. I was saying that a reliable
.children collection would be handy, and that the same result could be
achieved in browsers without .children with XPath (Firefox). That still
leaves a problem with browsers without .children _or_ XPath for HTML
documents, and those exist. Hence: not reliable, not recommended.
> Are you really suggesting eschewing the standard
> childNodes property for a call to that method?
You must have dreamed that. Read again.
- Conrad
PS: out of curiosity... who is Bullwinkle now, me or Steve Young?
David Mark
> On 24/05/09 21:08, David Mark wrote:
>
> > On May 24, 12:59 pm, Conrad Lender <crlen...@yahoo.com> wrote:
> >> The DOM2 specification doesn't define a "children" property for element
> >> nodes, AFAICS it's a non-standard extension.
>
> > As far as you can see?
>
> Depends on what is seen as the "standard". Not so long ago, Microsoft
> would have called their documentation the standard. And when most
> implementations support a feature, it could be argued to be a de-facto
> standard. (NB, I wasn't recommending to use .children)
>
> >> <tr>
> >> <td>...</td>
> >> <td>...</td>
> >> </tr>
>
> >> This TR element can have five childNodes (Firefox, Safari) or two
> >> childNodes (IE, Opera, Konqueror).
>
> > Your pigeonholes are laughable. And you wouldn't care in this case as
> > you are just filtering the white space.
>
> Pigeonholes, eh? Know any implementations that would find a different
> number than 2 or 5 in this case? Or do you mean that I should have
> mentioned more examples?
You should have kept your mouth shut, as is the case again.
>
> The need to filter the white space text nodes in laughable pigeonhole
> number 1 is the whole point. So yes, I do care.
You don't care how *many*, so whether they are "significant" or not is
irrelevant. Just filter them for all agents. *That* is the whole
point.
>
> >> (*) I guess you could try using XPath for browsers without a "children"
> >> collection, but I doubt that would be more reliable.
>
> > How many browsers support neither childNodes nor children, but have
> > document.evaluate?
>
> You completely misunderstood that. I was saying that a reliable
> .children collection would be handy, and that the same result could be
> achieved in browsers without .children with XPath (Firefox). That still
> leaves a problem with browsers without .children _or_ XPath for HTML
> documents, and those exist. Hence: not reliable, not recommended.
I misunderstood nothing. It makes no sense to use XPath when you can
just filter the childNodes, so why bring it up? And what about
Firefox?
>
> > Are you really suggesting eschewing the standard
> > childNodes property for a call to that method?
>
> You must have dreamed that. Read again.
>
> - Conrad
>
> PS: out of curiosity... who is Bullwinkle now, me or Steve Young?
Do you mean "SteveYoungGoogle" and "SteveYoungTBird?" They sound like
Two Stupid Dogs.
Thomas 'PointedEars' Lahn
> On May 24, 4:06 pm, Conrad Lender <crlen...@yahoo.com> wrote:
>> On 24/05/09 21:08, David Mark wrote:
>>> On May 24, 12:59 pm, Conrad Lender <crlen...@yahoo.com> wrote:
>>>> (*) I guess you could try using XPath for browsers without a "children"
>>>> collection, but I doubt that would be more reliable.
>>> How many browsers support neither childNodes nor children, but have
>>> document.evaluate?
>> You completely misunderstood that. I was saying that a reliable
>> .children collection would be handy, and that the same result could be
>> achieved in browsers without .children with XPath (Firefox). That still
>> leaves a problem with browsers without .children _or_ XPath for HTML
>> documents, and those exist. Hence: not reliable, not recommended.
>
> I misunderstood nothing. It makes no sense to use XPath when you can
Why?
PointedEars
Conrad Lender
> On May 24, 4:06 pm, Conrad Lender <crlen...@yahoo.com> wrote:
>>> Your pigeonholes are laughable. And you wouldn't care in this
>>> case as you are just filtering the white space.
>>
>> Pigeonholes, eh? Know any implementations that would find a
>> different number than 2 or 5 in this case? Or do you mean that I
>> should have mentioned more examples?
>
> You should have kept your mouth shut, as is the case again.
Touché, monsieur.
I bow before your convincing argument.
>> You completely misunderstood that. I was saying that a reliable
>> .children collection would be handy, and that the same result could
>> be achieved in browsers without .children with XPath (Firefox).
>> That still leaves a problem with browsers without .children _or_
>> XPath for HTML documents, and those exist. Hence: not reliable, not
>> recommended.
>
> I misunderstood nothing. It makes no sense to use XPath when you can
> just filter the childNodes, so why bring it up? And what about
> Firefox?
I see, the problem appears to be reading comprehension...
Firefox is a browser, right, with XPath support, but without support for
.children (in the released versions). Clearer now?
Why would it make sense to prefer XPath over a loop over childNodes and
a filter for nodeType? It's more convenient, less verbose, and easier to
read. A reliable .children collection would be even more convenient and
(probably) faster.
> Do you mean "SteveYoungGoogle" and "SteveYoungTBird?" They sound
> like Two Stupid Dogs.
I think we have a very different sense of humor.
- Conrad
David Mark
> On 24/05/09 22:24, David Mark wrote:
>
> > On May 24, 4:06 pm, Conrad Lender <crlen...@yahoo.com> wrote:
> >>> Your pigeonholes are laughable. And you wouldn't care in this
> >>> case as you are just filtering the white space.
>
> >> Pigeonholes, eh? Know any implementations that would find a
> >> different number than 2 or 5 in this case? Or do you mean that I
> >> should have mentioned more examples?
>
> > You should have kept your mouth shut, as is the case again.
>
> Touché, monsieur.
> I bow before your convincing argument.
>
> >> You completely misunderstood that. I was saying that a reliable
> >> .children collection would be handy, and that the same result could
> >> be achieved in browsers without .children with XPath (Firefox).
> >> That still leaves a problem with browsers without .children _or_
> >> XPath for HTML documents, and those exist. Hence: not reliable, not
> >> recommended.
>
> > I misunderstood nothing. It makes no sense to use XPath when you can
> > just filter the childNodes, so why bring it up? And what about
> > Firefox?
>
> I see, the problem appears to be reading comprehension...
Stop stealing my bits.
> Firefox is a browser, right, with XPath support, but without support for
> .children (in the released versions). Clearer now?
Nope.
>
> Why would it make sense to prefer XPath over a loop over childNodes and
> a filter for nodeType?
No idea.
> It's more convenient, less verbose, and easier to
> read.
Convenient in what way? Same for "easier to read." And one line or
six doesn't matter for something you write *once*. All trumped anyway
by the fact that it's XPath, which is spottily supported and buggy in
some implementations.
> A reliable .children collection would be even more convenient and
> (probably) faster.
But, even if it existed, it would be useless for now due to the
history of that method. How many times are we going to go over this?
>
> > Do you mean "SteveYoungGoogle" and "SteveYoungTBird?" They sound
> > like Two Stupid Dogs.
>
> I think we have a very different sense of humor.
Hard to tell from that context. I think you asked something about
you, Steve Young and Bullwinkle. I guess I didn't get it.
HTH.
Conrad Lender
> On May 24, 5:04 pm, Conrad Lender <crlen...@yahoo.com> wrote:
>> I see, the problem appears to be reading comprehension...
>
> Stop stealing my bits.
Must be tough being you. Everybody's stealing from you... Resig would
have been out of business if he hadn't copied all his best bits from you
(badly), kangax stole your isHostMethod function, and I'm stealing your
insults. We'd all be lost without you.
>> Why would it make sense to prefer XPath over a loop over childNodes and
>> a filter for nodeType?
...
>> It's more convenient, less verbose, and easier to read.
>
> Convenient in what way? Same for "easier to read." And one line or
> six doesn't matter for something you write *once*.
First of all, it's a nuisance. I don't like unnecessary boilerplate
code, I'd be happier if I could rely on the specialized accessors
provided by the API. Secondly, six lines here, six lines there, it adds
up. In an environment where the code has to be downloaded before it's
used, and where, today, users are expecting the sort of bling that
brings the (compressed) scripts to 30k or more in size, I'm even more
attracted to terse code. Maybe this isn't a priority for you, YMMV and
all that, but as you know there are scenarios where the byte count still
matters.
> All trumped anyway
> by the fact that it's XPath, which is spottily supported and buggy in
> some implementations.
I'm not saying there aren't any, but I've never heard of an XPath
implementation that's so messed up that it even fails at selecting a
node's child elements (named or not).
>> A reliable .children collection would be even more convenient and
>> (probably) faster.
>
> But, even if it existed, it would be useless for now due to the
> history of that method.
I don't understand what you mean by its "history" making it useless. If
you mean lack of support, then gEBI was "useless" a few years ago, and
now we use it every day without blinking (after feature testing, if
necessary).
- Conrad
David Mark
> On 24/05/09 23:15, David Mark wrote:
>
> > On May 24, 5:04 pm, Conrad Lender <crlen...@yahoo.com> wrote:
> >> I see, the problem appears to be reading comprehension...
>
> > Stop stealing my bits.
>
> Must be tough being you. Everybody's stealing from you...
You have no idea.
> Resig would
> have been out of business if he hadn't copied all his best bits from you
> (badly), kangax stole your isHostMethod function, and I'm stealing your
> insults. We'd all be lost without you.
You are such a moron.
[snip more nonsense]
Garrett Smith
> On 24/05/09 21:08, David Mark wrote:
>> On May 24, 12:59 pm, Conrad Lender <crlen...@yahoo.com> wrote:
>>> The DOM2 specification doesn't define a "children" property for element
>>> nodes, AFAICS it's a non-standard extension.
>> As far as you can see?
>
> Depends on what is seen as the "standard".
Some might consider the HTML 5 working draft a standard, though I do
think that is wrong. It is a working draft that does change (the <image>
element, for example, was removed from the spec).
The Element Traversal spec might have included a childElements property.
I said that on whatwg list I think two years ago. Ian commented on that.
Doug Schepers' Element Traversal API has some of that functionality,
though instead of nextSiblingElement, it is nextElementSibling (dislike).
Also the "childElements" property is missing from Element Traversal[1].
>
> The need to filter the white space text nodes in laughable pigeonhole
> number 1 is the whole point. So yes, I do care.
Not as important as a need to filter a comment.
>
>>> (*) I guess you could try using XPath for browsers without a "children"
>>> collection, but I doubt that would be more reliable.
>> How many browsers support neither childNodes nor children, but have
>> document.evaluate?
>
> You completely misunderstood that. I was saying that a reliable
> .children collection would be handy,
Yes, it would! Unfortunately, children includes comment nodes in IE.
Try a few browsers on the test below:
Chrome, Opera:
c.children.length: 2
c.children[1].tagName: EM
Firefox 3.0.10
HTML 5: "Not yet, but we're having fun trying."
IE 5.5- IE 8:
c.children.length: 3 c.children[1].tagName: !
See? IE includes the comment node. They call that an element and gave it
the tagName "!".
The MSDN documentation for IE for children[2] property states:
| children Collection
|
| Retrieves a collection of DHTML Objects that are direct descendants of
| the object.
Microsoft has a list of "DHTML Objects"[3] that is linked from the above
sentence. The page for DHTML Object includes |comment| in the list.
In contrast, the windows mobile documentation for children[4] states:
Windows Mobile Version 5.0 SDK
| children HTML Collection
| Send Feedback
|
| The children collection contains all the elements that are a direct
| descendant of the object.
That mobile documentation also states that children.length "Always
returns 0."
Microsoft probably includes comments in its definition of "element", but
I could not see the MSDN definition of "element".
Gecko includes a children[5] property for Firefox 3.5 and the
documentation states:
| children returns a collection of child elements of the given element.
The w3c's Element Traversal Specification[1] includes a few traversal
properties that are not well-named and sorely excludes a childElements
property. I brought this up over a year ago on the w3c list, and to the
usual effect of no change to the specification. John Resig even blogged
about this recently and apparently miscalled the properties. What he
miscalled them, I don't know, but I would not be surprised if he used
"nextSiblingElement" instead of "nextElementSibling". That seems to me
to be a more intuitive name. In fact I have seen a fair amount of other
ocde use "nextSiblingElement" for the function's name. Not trying to
nitpick on John Resig here. My point is that the nextElementSibling is
not as intuitive as "nextSiblingElement".
Example:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>whitespace</title>
<script type="text/javascript">
window.onload = function() {
var c = document.getElementById('c'),
m, s;
if("children" in c) {
s = [
"c.children.length: " + c.children.length,
"c.children[1].tagName: " + c.children[1].tagName];
document.getElementById("m").firstChild.data = s.join("\n");
}
};
</script>
</head>
<body>
<h1 id="c"><strong>hey</strong><!-- you --><em>bobo</em></h1>
<pre id="m">HTML 5: "Not yet, but we're having fun trying."</pre>
</body>
</html>
Garrett
[1]http://www.w3.org/TR/2008/REC-ElementTraversal-20081222/
[1]http://msdn.microsoft.com/en-us/library/ms537446(VS.85).aspx
[2]http://msdn.microsoft.com/en-us/library/ms533054(VS.85).aspx
[3]http://msdn.microsoft.com/en-us/library/ms881541.aspx
[5]https://developer.mozilla.org/en/DOM/Element.children
Thomas 'PointedEars' Lahn
> On 24/05/09 23:15, David Mark wrote:
>> On May 24, 5:04 pm, Conrad Lender <crlen...@yahoo.com> wrote:
>>> I see, the problem appears to be reading comprehension...
>> Stop stealing my bits.
>
> Must be tough being you. Everybody's stealing from you... Resig would
> have been out of business if he hadn't copied all his best bits from you
> (badly), kangax stole your isHostMethod function, and I'm stealing your
> insults. We'd all be lost without you.
YMMD :)
Regards,
PointedEars
rf
Crikey. Here I am preparing a post wherein I will admit the following:
I agree with PointedEars.
There, I have said it. A load off my mind.
Mark used to be entertaining. Not so any more.
You sir, Mr Ears, are still entertaining :-)
--
Richard.
David Mark
I am not here for your entertainment. Though I'll admit that YMMD was
a slayer.
David Mark
wrote:
You would, dumb-ass. Need I remind you?
Garrett Smith
> Conrad Lender wrote:
>> On 24/05/09 21:08, David Mark wrote:
>>> On May 24, 12:59 pm, Conrad Lender <crlen...@yahoo.com> wrote:
[...]
> Microsoft probably includes comments in its definition of "element", but
> I could not see the MSDN definition of "element".
>
MSDN: Comments *are* elements.
http://msdn.microsoft.com/en-us/library/ms533029(VS.85).aspx
| HTML Elements
|
| This section contains a list of elements defined by HTML. The links
| take you to the element definitions, which contain the set of members
| for the element.
|
[...]
|
| comment
|
| Indicates a comment that is not displayed.
Not surprising, as comments have been included in the collection
returned from getElementsByTagName("*") for as long as I can remember.
Seems to be still in IE8.
Changing the example (below) to use getElementsByTagName("*") will
include the comment node.
IE8 result:
text1text2
els.length: 3
els[1].tagName: !
Example:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>getElementsByTagName("*") - comment nodes</title>
<script type="text/javascript">
window.onload = function() {
var c = document.getElementById('c'),
m, s, els = c.getElementsByTagName("*");
s = [
"els.length: " + els.length,
"els[1].tagName: " + els[1].tagName];
document.getElementById("m").firstChild.data = s.join("\n");
};
</script>
</head>
<body>
<h1 id="c"><strong>text1</strong><!-- comment node --><em>text2</em></h1>
<pre id="m">-</pre>
</body>
</html>
There you have it. In IE, comments are Elements.
Garrett
David Mark
> Garrett Smith wrote:
> > Conrad Lender wrote:
> >> On 24/05/09 21:08, David Mark wrote:
> >>> On May 24, 12:59 pm, Conrad Lender <crlen...@yahoo.com> wrote:
>
> [...]
>
> > Microsoft probably includes comments in its definition of "element", but
> > I could not see the MSDN definition of "element".
>
> MSDN: Comments *are* elements.
>
> http://msdn.microsoft.com/en-us/library/ms533029(VS.85).aspx
Yes, their tagName is "!". This has always been the case with IE.
Did you mention they did *not* fix this in IE8?
>
> | HTML Elements
> |
> | This section contains a list of elements defined by HTML. The links
> | take you to the element definitions, which contain the set of members
> | for the element.
> |
> [...]
> |
> | comment
> |
> | Indicates a comment that is not displayed.
>
> Not surprising, as comments have been included in the collection
> returned from getElementsByTagName("*") for as long as I can remember.
> Seems to be still in IE8.
Odd behavior like that is a reason to avoid passing "*" to gEBTN.
IIRC, older Safari browsers choke on it as well, returning nothing.
[snip]
kangax
[...]
> IE8 result:
>
> text1text2
> els.length: 3
> els[1].tagName: !
In FF3.5beta4, we get:
c.children.length: 2
c.children[1].tagName: EM
And in Safari 3.0.4+:
c.children.length: 2
c.children[1].tagName: EM
So that makes it 4 browsers - Safari 3.0.4+, Chrome 1+, Opera 8.54+ and
Firefox 3.5+.
Very nice.
Testing for which elements are returned by `children` is trivial and
could be done at load time. If it happens to be "conforming" (whatever
"conformance" would mean in particular case), then I don't see a reason
not to prefer it to `childNodes`. Code size aside, it would definitely
be *faster* than iterating over `childNodes` and filtering out
comment/text nodes, wouldn't it? I'm guessing such performance
difference could be quite beneficial when working with large trees, so
why not take advantage of it (after all the precautions)?
[...]
--
kangax
kangax
I played a little more with `children` (no pun intended). Some fun facts:
Safari 2.x has a nasty bug. It seems to return *all* descendants - not
just immediate ones. Clearly, that bug needs to be feature tested before
attempting to use `children`.
In Firefox 3.5 beta4, children based solution is ~50 times faster than
manual iteration/filtering. In Opera 10b that number is ~460 (!!!) and
in Safari 3.04 - 250. The test was run in a context of merely 95 child
elements with varying depth.
Here's an implementation that I used for testing. I can attach an entire
testcase (with HTML) if anyone is interested:
...
<script type="text/javascript">
(function(){
function childNodes(element) {
var children = element.childNodes,
result = [];
for (var i = 0, len = children.length; i<len; i++) {
var child = children[i];
if (child.nodeType == 1) result.push(child);
}
return result;
}
function children(element) {
return element.children;
}
var elTestee = document.body;
var t = new Date();
for (var i=10000; i--; ) {
childNodes(elTestee);
}
var t1 = new Date() - t;
t = new Date();
for (var i=10000; i--; ) {
children(elTestee);
}
var t2 = new Date() - t;
var l1 = childNodes(elTestee).length;
var l2 = children(elTestee).length;
document.write(t1 + 'ms; ' + l1 + ' elements found<br><br>');
document.write(t2 + 'ms; ' + l2 + ' elements found');
})();
</script>
...
--
kangax