Let op: Tweakers stopt per 2023 met Tweakblogs. In dit artikel leggen we uit waarom we hiervoor hebben gekozen.

Heads or Tails?

By crisp on maandag 17 mei 2010 01:49 - Comments (14)
Categories: Browsers, Javascript, Webdevelopment, Views: 15.185

Clientside Performance Guru Steve Souders recently created a test to see if browsers implicitly create a <head>-element for all HTML documents. I pointed out in the comments that there might be more in play than just the fact that some browsers don't follow the specifications (notably mobile browsers) to the letter with regards to DOM-tree building.

It started with the question why Google had abandoned the practice to just append scripts to the <head>-section of a document in order to dynamically load additional scripts in an asynchronous matter. For instance, Google Analytics now uses this technique for asynchronous loading:
var ga = document.createElement('script');
ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ?
    'https://ssl' : 'http://www') +
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(ga, s);

The main problem with a simple approach such as just appending newly created scripts to the <head> (by using f.i. document.getElementsByTagName('head')[0].appendChild()) is that some documents (and in some browsers) don't appear to have a <head> in the DOM.

So Google's new approach does seem to make sense and is probably more robust, but it leaves the question: why do some browsers don't implicitly create a <head>-element in the DOM-tree? And more importantly: which browsers? The answer to that last question may be important to determine the scale of the problem and its impact on determining which way is the best approach to dynamically load external javascript files.

I pointed out in the comments to Steve's blogpost that there may be more to it than just a browsers' failure to adhere to the applicable specifications, although Steve's testresults already showed that some specific browsers (and on some specific mobile platforms) that don't implicitly create a <head>-element in the DOM-tree make up a sufficient share such that relying on that is currently unwise.

However, Steve indirectly asked me to create my own browsertest in order to explore this issue further and to see if for instance quirksmode would make a difference. I already knew for a fact that a <head>-less document in true XHTML (served as application/xhtml+xml) would normally not have a <head>-section in the DOM (and I used this as a teaser because Steve used an XHTML doctype on his testpage, but served it as text/html).

So, even though I could have declined, and with my time being quite limited by work and family (and the fact that it's already way past midnight that I'm writing this blogpost) I decided to take up on his request and created my own browsertest:

You can take the test here: implicit HEAD test

I ask everyone to take this test in as many browsers as possible. Preferably older browserversions and mobile browsers (they do have to have javascript support and some level of DOM-support though).

Here's some explanation to the labels for the various tests:

Base: A quirksmode document starting with a BASE-element
Explicit: A standards-compliant document that does have an explicit HEAD-element (so in all browsers this should give a positive result)
Quirksmode: A quirksmode document that doesn't have HTML, HEAD or BODY
Valid: A standards-compliant document but with HTML, HEAD and BODY omitted
XHTML: A standards-compliant document with an XHTML doctype and served as application/xhtml+xml that doesn't have a HEAD-element

Note that, as already mentioned above, I do expect most browsers to 'fail' (as in: reporting it to not have a <head>-section in the DOM) the 'XHTML' test since it is an XML application and not SGML (or HTML5). I deliberately skip this test in IE-based browsers since IE doesn't have real XHTML support.


Volgende: DHTML Lemmings primer 05-'10 DHTML Lemmings primer
Volgende: The real reason Apple and Microsoft are embracing 'HTML5' 05-'10 The real reason Apple and Microsoft are embracing 'HTML5'


By Tweakers user Jeoh, maandag 17 mei 2010 02:56

http://j.mp/ajjnBB for the people with mobile browsers :)

I've tested it with Google Chrome 5 and the Blackberry Browser, which actually performed better.

By Carey Evans, maandag 17 mei 2010 04:41

Another reason for Google’s change may be that using insertBefore() doesn’t seem to trigger IE’s “Operation aborted” error. appendChild() was only OK if it was used from the very last element in the head.

By Tweakers user !GN!T!ON, maandag 17 mei 2010 07:11

chrome fails the xhtml test here

By Tweakers user Oxiounking, maandag 17 mei 2010 07:56

IE5.5, IE6, Konqueror 4.4, Firefox 1, Firefox 1.5, Firefox 2.0, Firefox 3.0 tested.

Also tried IE5 (partly succeeds, but stops halfway through), IE4 and IE3, but they fail the tests.

[Comment edited on maandag 17 mei 2010 08:07]

By Tweakers user Puc van S., maandag 17 mei 2010 08:46

FF3.6 fails the xhtml test, the default android 2.1 browser succeeds every test.

By Tweakers user crisp, maandag 17 mei 2010 09:30

I would expect every browser to 'fail' the XHTML test since it's an XML application and not SGML (or HTML5) - I will clarify that in my blogpost :)

By Tweakers user FlowinG, maandag 17 mei 2010 09:38

I tried the test on my HD2 with Opera and Internet Explorer. Opera is identified as Opera 9.7 and Internet Explorer as IE 6.0 by Browserscope.

Xhtml (#4) was skipped while testing with Internet Explorer.

[Comment edited on maandag 17 mei 2010 09:38]

By Tweakers user Lye, maandag 17 mei 2010 09:59

Alright, so I tried with Chromium 6.0, Iceweasel 3.5.9 and Epiphany (Which is somehow classified as 'Other', linux hater :(). All produce the same output, everything works except for XHTML

[Comment edited on maandag 17 mei 2010 09:59]

By Tweakers user RoadRunner84, maandag 17 mei 2010 11:03

I tested using Iron (a Chrome derivate, lacking privacy sensitive features such as search query hinting). Results as expected: all create a head in the tree, except for the XHTML application, which does not create such an entry.

By Tweakers user Kale Kiwi, maandag 17 mei 2010 11:53

Tried it on my HTC Desire with the default browser which indentifies as Android 2.1, passed all tests...

[Comment edited on maandag 17 mei 2010 11:53]

By Tweakers user YopY, maandag 17 mei 2010 11:55

The test doesn't work at all in IE 3.0 :+. IE 5.01 crashes on that page, IE 5.55 works on all but the XHTML test (#4) (it skips that one), IE 6 and IE 8 has the same result.

By Tweakers user RoadRunner84, maandag 17 mei 2010 12:06

The Yorick wrote on Monday 17 May 2010 @ 11:53:
Tried it on my HTC Desire with the default browser which indentifies as Android 2.1, passed all tests...
Which is not good, because XHTML should not implicitly populate the header in the DOM tree +)

By Tweakers user hostname, maandag 17 mei 2010 15:29

I've tested Android 2.1 (everything ok) and Symbian S60 (fails 3 and 4).

By Tweakers user afraca, woensdag 19 mei 2010 17:48

Bit late perhaps, but maybe worth mentioning.... The Google Chrome dev-channel release has reached version 6, user agent string still identifies as version 5? Only failing test 4.

Firefox 3.6.3 (Linux) only fails test 4.

Opera 10.53 build 6330 (Linux) only fails test 4.

Sorry, don't have any outdated browsers here....

Comments are closed