Re: Executing script-inserted external scripts in insertion order

Adam Barth wrote:
> As well as being declarative, the waitFor proposal also supports more
> use cases than the other proposal because it doesn't force a linear
> dependency graph.

Forcing linear dependencies is a feature: It makes it impossible to create dependency loops.

One way to have multiple dependency groups while making dependency loops impossible would be making script nodes have a .group DOMString property. A script would block on any pending script that was inserted earlier and that has the same group name. But even this would be over-engineering compared to what Kyle proposed.

I prefer the approach that defaults .async to true for script-created scripts (including scripts that have lost their parser-insertedness!). I like it because it has two parts (a new script queue and a new default for async) and one of the parts alone (the new queue) is the obvious firefight fix one would make to Firefox 4 if beta exposure showed enough UA-sniffing-based site breakage that'd be deemed too late to evangelize for Firefox 4. That is, landing both parts (the queue and the new default for async) would still make it possible to chicken out before release and back out the new default part leaving the new queue part. (We don't yet have beta exposure for HTML5-compliant script execution in Firefox, so in that sense this whole discussion is premature and beta exposure data could force me to reconsider.) If the new default was deferred to the next major release after Firefox 4, it would still be possible to write a script library like LABjs in a way that'd be compatible with Firefox 3.6, 4.0, the release after 4.0 and a hypothetical WebKit release that defaulted async to true earlier than Firefox by explicitly assigning true or false to .async on every script-inserted external script.

Apart of the complexity of doing id lookups, etc., for waitFor, one of the reasons why I'm averse to introducing new API surface is that it is relatively late in the Firefox 4 cycle (in principle past feature freeze) but I think we should give LABjs some solution to address its use case (since failing to address the use case would count as a regression). In addition to the feature freeze, introducing new API surface would open up the issue of whether to moz-prefix the API at this point. Of course, moz-prefixing would poison any cross-browser feature-sniffing forward-compat story. Failure to prefix might be a problem, too, if a complex API were being introduced and there were room for spec bugs. Hijacking .async has neither problem. The proposed solution is so simple that the chance of interop-sensitive spec bugs arising form the change would be virtually zero. Also, hijacking existing API surface would pre-empt the moz-prefixing issue.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 19 October 2010 07:39:03 UTC