Comments on: Adventures With document.documentElement.firstChild

By: Performance Calendar » The art and craft of the async snippet

Performance Calendar » The art and craft of the async snippet — Mon, 05 Dec 2011 10:16:53 +0000

[...] document.documentElement is the HTML element and its first child must be the head. Not necessarily, as it turns out. If there’s a comment following the HTML element, WebKits will give you the comment as the first child. Here’s an investigation with a test case. [...]

By: Robert

Robert — Sat, 26 Dec 2009 23:44:25 +0000

@James: Thanks, that’s an old bug I totally forgot about. It’s now fixed so next time it should show correctly.

By: James

James — Mon, 14 Dec 2009 16:06:38 +0000

This post is a bit confusing on planet mozilla, as the HTML is partly parsed instead of displayed, so the comment is missing.

By: Ms2ger

Ms2ger — Sun, 13 Dec 2009 14:02:35 +0000

According to HTML5, you should get the comment. (Relevant part of the spec: The "before head" insertion mode.) Mozilla's HTML5 parser matches the spec here.

By: Robert

Robert — Sun, 13 Dec 2009 01:08:05 +0000

@Sean Hogan: Virtually all js libraries make it easy too for example $(“head”) will work in jQuery.

By: Sean Hogan

Sean Hogan — Sun, 13 Dec 2009 00:05:45 +0000

If you need to access document.head more than once it is probably worth adding it (if it doesn’t already exist):

if (!document.head) document.head = document.getElementsByTagName(“head”)[0];

This should always work in HTML pages, even if the script occurs before the tag.

By: Robert

Robert — Sat, 12 Dec 2009 22:59:32 +0000

@google analytics: The new code I think is pretty solid since it leaves little to chance. I’m pretty sure even I won’t manage to break it, at least from the implementers standpoint.

@Boris: My expectations were admittedly based on previous experience more than specs. Not sure if I’ve ever run across a situation exactly like this before.

@Matt: I’m aware of document.head, though I don’t foresee using that for quite some time when 99% of the world runs a web browser that will work on. At the rate we’re going that’s 2029.

By: Matt

Matt — Sat, 12 Dec 2009 22:21:51 +0000

FYI document.head was added to HTML5[1] to simplify this case. The issue you found was discussed[2] on the whatwg list as one of the reasons for a better way to access the head of the document. Hopefully it will be one less browser compat. issue to worry about once implemented.

[1] http://www.whatwg.org/specs/we.....ument-head
[2] http://lists.whatwg.org/htdig......23105.html

By: Boris

Boris — Sat, 12 Dec 2009 22:14:23 +0000

The DOM spec is the wrong place to look for this, since your question is really what the DOM should look like. The relevant spec there would be the one that covers how to convert HTML source into a DOM: the HTML parsing spec. There isn’t one at the moment, though HTML5 is working on it. So currently behavior is undefined. Not sure what the HTML5 draft proposes for the behavior.

In particular, whitespace before is treated magically in various UAs and in the HTML5 draft last I checked; comments may or may not be depending. It’s interesting that you didn’t expect firstChild to be the textnode coming before the comment; why not?

By: google analytics

google analytics — Sat, 12 Dec 2009 21:54:55 +0000

Thanks for writing this! Its good to get this documented. We were aware of the issue…we just underestimated the number of sites with this with comments above the head. We made the wrong tradeoff. The new code isn’t as terse, but it should cover pretty much any page you throw at it.