- From: Getify <getify@gmail.com>
- Date: Mon, 18 Oct 2010 00:13:59 -0500
- To: "Adam Barth" <w3c@adambarth.com>, "public html" <public-html@w3.org>
?> He looked at (some of) the sites listed before and didn't see any > problems. Maybe we need to study them in more detail. I understand that several people have pulled up the sites listed and haven't noticed right off the bat the breakage. But this is not a valid assertion that such breakage is not (or won't be) occurring. I am going to explain here *why* such breakage is guaranteed based on logic. That should be superior to observed (or unobserved) breakage unless you happen to be an expert on all the JavaScript UX that every site you inspect should have -- if you are that familiar, such breakage will be obvious, but if you're not that familiar, breakage can easily be missed. I am obviously that familiar with my two sites (flensed.com and blog.getify.com), and I have tested them both in Webkit nightly and in FF nightly, and I can verify they do in fact break. What breaks in FF for instance is that the Twitter feed fails to finish loading. The breakage observation notwithstanding, there is some undeniable logic happening here, and I can definitively state based on how I know LABjs works (since I wrote it) what usage will in fact break based on the changes by Mozilla and Webkit. The sites listed do have patterns of LABjs usage that will break. For instance, to illustrate: $LAB .script("foo.js").wait() .script("bar.js").wait() .script("http://domain.tld/baz.js").wait() .script("http://another.tld/blah.js") .wait(function(){ // do something }); This chain represents a pattern that is in use on all 3 of the sites I have mentioned in this thread. (there are other examples out there, but these should be instructive enough). This chain pattern will now break in both FF and Webkit. Here's why: * FF -- there's a race condition that "baz.js" and "blah.js" will, while loading in parallel, execute "as soon as possible", meaning that even though the .wait() between "baz" and "blah" expresses that there's dependency that necessitates them going in order. LABjs has been relying on the ordered execution of such scripts in FF (and Opera), and now that this ordering is no longer enforced, a race condition *definitely* exists. This is unquestionable. * Webkit -- neither "baz.js" nor "blah.js" will even be fetched in Webkit with the new change, because LABjs will try to "preload" them by using a <script> with `type=script/cache`, which Webkit will no longer download (as it did previously). It's clear (and again, unquestionable) why that will now break in Webkit. > I believe defer doesn't wait until onload. It just wants for parsing > to be finished, which is considerably earlier: > > http://www.whatwg.org/specs/web-apps/current-work/#attr-script-defer I never said "onload", I said "waits on the DOM". So yes, this is waiting on `DOMContentLoaded`. However, it's also important to note that `defer` behavior is *not* defined by spec for script-inserted scripts. So an on-demand script loader (doing script loading either during page load or later) cannot rely on `defer` for the desired behavior. > Honestly, I'm lost w.r.t. all the proposals. ------------------------------------------------- OK, so there's lots of confusion because the thread has already gotten very long and diverted around several rabbit trails. Let me restate the proposal clearly: 1. Extend the behavior of the `async` property to script-inserted scripts (currently only spec'd for parser-inserted scripts). This means that `async=true` on script-inserted script nodes would load all of them in parallel and execute each "as soon as possible". This is basically exactly like script-inserted scripts work in IE/Webkit right now. `async=false` on script-inserted nodes would load them all in parallel, but preserve execution order as insertion-order. 2. It is still up for decision what the default value for the `async` property should be for script-inserted scripts. For parser-inserted scripts, the default is `false`, obviously. I believe that for compat reasons and for feature-test reasons, the default makes more sense to be `true`. This would mean that by default, script-inserted script nodes in IE/Webkit would continue to behave like they currently do, in addition to FF nightlies. But the ordered execution would be available to such scripts if the author changed `async` from its default of `true` to `false`. ------------------------------------------------- --Kyle
Received on Monday, 18 October 2010 05:14:37 UTC