Nicolas Mendoza wrote:
Try adjusting the timeout:
http://people.opera.com/nicolasm/test/domcontentloaded.html?timeout=10
http://people.opera.com/nicolasm/test/domcontentloaded.html?timeout=60
That test has a <script> after the <link>. Since scripts sometimes depend on
style information being up to date by the time they're run, Gecko (even Gecko
1.9) won't run that script until the stylesheet has finished loading. And since
scripts block the parser (due to document.write), DOMContentLoaded automatically
fires after scripts have all run.
Simply switching the order of the <link> and <script> tags in that document
should give you different behavior there with Gecko 1.9... That's not great in
and of itself, but such is life.
Anyway it's not that important what it actually does, as long as it's
defined somewhere what it is supposed to do.
Like it says in the spec, it fires when parsing has finished. The ordering of
this with other things (like loading of images, stylesheets, etc) is undefined.
People really shouldn't depend on a particular ordering there.
I think it _should_ be safe to assume that non-deferred scripts have loaded and
run before DOMContentLoaded (again, due to document.write).
And as mentioned in the blog post, it could be fatal if DOMContentLoaded is used with common 3rd
party libs that expect styles to already have been applied when being
run.
The example linked in that blog post has problems in general -- since it's using
DOMContentLoaded to run script that looks at sizes of CSS boxes, it'd also break
if there were intrinsically-sized images around.
One might want to think of having events with higher granularity
being fired during a loading/parsing process.
Like what, between "all of the DOM is here" and "this page is fully loaded"?
What are the usecases? Again, the use case in the blog post really needs "this
page is fully loaded", or at least "everything that can affect the layout of the
page is fully loaded".
-Boris
