<div>FWIW, loading scripts asynchronously with the "Script DOM Element" approach does not block window.onload in IE.  In Chrome and Safari, the downloading blocks, but execution doesn't.  In Firefox and Opera, downloading and execution blocks.<br>

</div><div><br></div><div>So, it's pretty hard to say what web developers would expect with async scripts.  I know that they will like having things like ads and analytics not block window.onload though.  At the very least, we need that ability to make that happen.  </div>

<div><br></div><br><br><div class="gmail_quote">On Sat, Feb 13, 2010 at 12:15 PM, Boris Zbarsky <span dir="ltr"><<a href="mailto:bzbarsky@mit.edu">bzbarsky@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On 2/13/10 9:29 AM, Darin Fisher wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The Mozilla network code uses the phrase "load background" to describe a<br>
load that happens asynchronously in the background _and_ does not block<br>
onload.  Perhaps not coincidentally, this mode is used to load<br>
background images :-)<br>
</blockquote>
<br></div>
It used to be.  It's not anymore, because it was not compatible with what other UAs did or with web developer expectations.  At this point the background mode is only used for async XHR, and then only because background modes don't make the throbber spin.  Otherwise we wouldn't use it for anything at all.<br>


<br>
Which is my real worry about making any loads that don't block onload: would web developers expect them to?<br><font color="#888888">
<br>
-Boris<br>
</font></blockquote></div><br>