kyle added....

To answer @paulirish's earlier question (https://github.com/paulirish/html5-boilerplate/issues/28#issuecomment-1765361) about defer quirks, look at how "DOMContentLoaded" behaves across IE, Chrome, and Firefox in the defer test.

In IE9 and Chrome15, the DOMContentLoaded event is held up (blocked) and not fired until after the scripts run. In FF, however, the DOMContentLoaded event is not held up, it fires right away, and the scripts start executing after it. That's a giant inconsistency across modern browsers, and one of the reasons why I don't think defer is sufficient.

Spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#attr-script-defer

To give more context to the above list of defer issues:

1. defer doesn't have any meaning in dynamic script loading. But it doesn't need to, because of the new "ordered async" (async=false) that IS spec'd and now in almost all browsers' current releases. What's confusing though is that you have to use defer when you're dealing with markup, and async=false when you're dynamically creating script elements. The latter would make you assume you could/should use async in markup, but that's not going to work because order is not preserved -- unless of course you happen to not care about order.
2. this is now proven (partially documented) by this video: http://www.screenr.com/icxs To save you from having to watch it, though, IE9 and Chrome15 both block the DOMContentLoaded event (aka, "DOM-ready") until after all the defer scripts finish, whereas FF8(nightly) does not block the event. I'm willing to bet there are other browsers which fall on both sides of that issue, as well, as the spec seems a bit confusing on this particular point (at least in my reading).
3. It seems from some older blog posts that at one point, inline script blocks could have defer set on them, and browsers would respect that. http://hacks.mozilla.org/2009/06/defer/ However, as that video above clearly illustrates, none of the current browsers respect that, and in fact, reading the spec, defer is NOT defined for inline script blocks. That makes it uber-difficult to convert an existing set of script tags (some external, some inline) to use defer, if those inline blocks are relying on ordering (almost always they are).
4. I don't have much evidence of this, but I know a guy who's done a bunch on this, and I'll ping him to get some more specifics. I stay far the hell away from document.write(), but some unfortunate souls have to deal with that reality (aka, "nightmare").

I made a test which seems to confirm the following:

In FF, however, the DOMContentLoaded event is not held up, it fires right away, and the scripts start executing after it. That's a giant inconsistency across modern browsers, and one of the reasons why I don't think defer is sufficient.

http://dl.dropbox.com/u/513327/domload_defer.html (load and reload it in Firefox 5 and then load in Chrome)

Chrome 12 results: expected: number; got: number;
Firefox 6, 5, 4, 3.6 results: expected: number; got: undefined;
Firefox 3.5, 3.0 results: expected: number; got: number;

Update: I removed the Cuzillion tests on visual rendering blocking because they were invalid.

Isn't blocking the visual rendering only supposed to occur with non-defered scripts? What would be the advantage of defer then? I'd say all is well with how FF 3.5+ and Safari handle it. Safari 4 and sorts blocking may just be indication that they don't recognize a defer-attribute yet.

In regards to DOMContentLoaded event being triggered too early, maybe the following manual DOMContentLoaded triggering technique may be of interest for a fix: http://stackoverflow.com/questions/942921/lazy-loading-the-addthis-script-or-lazy-loading-external-js-content-dependent-o

if( document.createEvent ) {
 var evt = document.createEvent("MutationEvents"); 
 evt.initMutationEvent("DOMContentLoaded", true, true, document, "", "", "", 0); 
 document.dispatchEvent(evt);
}

@Schepp

In regards to DOMContentLoaded event being triggered too early, maybe the following manual DOMContentLoaded triggering technique may be of interest for a fix

I think that might cause problems with some handlers as it's generally assumed DOMContentLoaded is only fired once.

FWIW:

[22:36] <matjas> is there a point in using @defer when you only use a single <script> and it’s at the bottom, right before </body>?
[22:36] <Hixie> not really
[22:38] <matjas> not really or not at all?
[22:38] <matjas> what is the point?
[22:39] <Hixie> there's no point that i can think of
[22:39] <Ms2ger> Being fancy! :)
[22:39] <Hixie> there are some subtle minor differences, but nothing useful i don't think

Source

Are the logical next steps to:
a) define and agree on the test cases?
b) define and agree on the testing methodology?
c) create solid test pages
d) do the testing

@jdalton

I ran your DCL test page (http://dl.dropbox.com/u/513327/domload_defer.html) in IE9: expected: number; got: number;

The question is: What is our goal here (in regards to H5BP)? Upgrading all scripts which are already aligned at the document's end with defer? Even if we wouldn't have a DOMContentLoaded discrepancy between browsers we would not gain anything performance-wise. deferreally makes sense when you have like a stubborn CMS that cannot queue scripts for an insertion at the very end. But then again, you cannot generally auto-deferall scripts that you come across as they might contain a document.write or they are accompanied by some (officially) non-deferable inline-script. So the main problem is that even if all browsers would follow one standard, it will never be a no-brainer solution.

What we could do is do some tests just for fun and curiosity (which might be reason enough ;)

Isn't the visual rendering blocking/non-blocking that @jdalton reported expected? The report HTML on the Cuzillion page comes after the external script. So doesn't it make sense that it would be blocked without defer and not blocked with defer?

@robflaherty Good point. This:

…appears after the last <script> in the test page HTML, so it’s not really a test case of <script defer src=foo></body>.

If the defer attribute were defined that it should push the scripts to start executing immediately after it fired the DOMContentLoaded event (like it does in FF), then defer would be useful even at the end of the body, because drastically speeding up DOM-ready is quite effective in improving the "perceived performance" of a site, which makes users think the site actually did load quicker, even if it loaded slower overall.

As it stands, defer seems somewhat more useful in FF than in IE9 and Chrome15.

If "defer" is made the default, will developers get confused that their inline JS is processed before the deferred (external) scripts?

http://www.artzstudio.com/files/Boot/test/benchmarks/script.defer.html

Most sites have a need for inline JS, for example Google Analytics code, page specific initialization, etc.

• update looks like Cuzillion says this should work... :/
  http://stevesouders.com/cuzillion/?c0=hj1hfft2_0_f&c1=hj1hfft2_0_f&c2=hb0hfff0_0_f&t=1313075137650

Couple of other points... it may be worth noting that stylesheet downloading blocks DOMContentLoaded only if the stylesheet is followed by scripts. Adding defer changes this and causes DOMContentLoaded to fire before the stylesheet has finished downloading. Probably not a common scenario but I thought I'd mention it.

Example: http://stevesouders.com/cuzillion/?c0=hc1hfff2_0_f&c1=bj1hfft1_0_f&t=1313073628

Another thing to keep in mind when testing is WebKit's PreloadScanner, which prefetches scripts and runs in just about every real-world scenario. In more cases it's surely tangential but there may be some wacky test cases where it affects results.

An user reported the suggested fix didn't work for him. If other users could confirm this, the original post should be edited so that people who land on it are not misled ;)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This issue has been automatically closed because it has not had recent activity. Thank you for your contributions.