Re: Executing script-inserted external scripts in insertion order

On Tue, Oct 19, 2010 at 10:58 PM, Adam Barth <w3c@adambarth.com> wrote:
> On Tue, Oct 19, 2010 at 12:38 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
>> 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.
>
> I have two problems with your proposal:
>
> 1) Decoupling the async attribute from the async property is ugly.
> 2) Adding yet-another-script-execution queue is added complexity to an
> already extremely complex and subtle area.
>
> If we're going to address this use case, we should nail it so we don't
> have to come back and hack it up some more next year, Firefox release
> schedules not withstanding.

Here's another proposal for addressing this use case:

document.executeScripts(['foo.js', 'bar.js', 'qux.js']);

This fetches the scripts asynchronously and executes them in order.
Notice that you can use this API to create independent linearly
ordered queues of asynchronous script execution.

Adam

Received on Wednesday, 20 October 2010 08:09:29 UTC