Re: Executing script-inserted external scripts in insertion order

Adam Barth wrote:
> On Tue, Oct 19, 2010 at 10:58 PM, Adam Barth <w3c@adambarth.com>
> wrote:
> > I have two problems with your proposal:
> >
> > 1) Decoupling the async attribute from the async property is ugly.

I agree it's ugly from a browser implementor POV.

However, I doubt authors would consider it ugly. In fact, I doubt authors appreciate the logic of the mechanics of reflecting DOM properties. See this comment thread:
http://html5doctor.com/html5-simplequiz-3-how-to-mute-a-video/#comments

I'd expect it to be uglier for authors that async only affects parser-inserted scripts and has no effect on script-inserted scripts (except in Firefox 3.6). What's the point of having a reflecting DOM property if setting it never does anything useful and reading it is pretty useless, too. Why would you care reading the async property of a parser-inserted script? Having the property in the DOM suggests that it does something useful. As currently specced, the property seems to be there just for completeness, but it's useless to get or to set the property. Language design like that just sets up weirdness for authors to spend time poking at unsuccessfully.

> > 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.

So in order to avoid adding one script execution queue, you propose adding an arbitrary number?

I can see issues with executing scripts without script elements:
 * How does one register an onload or an onerror handler? I'd expect JS libraries that currently provide script loader APIs not to want to lose the ability to register onload or onerror handlers.
 * What value would document.currentScript have when a script loaded via document.executeScripts is executing?
 * Would onbeforescriptexecute and onafterescriptexecute handlers be supported? If yes, how would one register the handlers and what would the .target property of the event objects be?

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

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