W3C home > Mailing lists > Public > public-html@w3.org > October 2010

Re: Executing script-inserted external scripts in insertion order

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 20 Oct 2010 09:31:33 -0700
Message-ID: <AANLkTimCKA9j0g9aEf6u5yz2aBoq7+24mOnnaahfaA-J@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: public html <public-html@w3.org>
On Wed, Oct 20, 2010 at 1:48 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
> 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?

Yes.

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

Alternatively, one could structure the API more like XMLHttpRequest
and return a ScriptLoader object with various methods.

>  * What value would document.currentScript have when a script loaded via document.executeScripts is executing?

What values does document.currentScript have when running setTimeout
or an event handler?

>  * 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?

I'm not familiar with these events.  Are they part of HTML5?

Adam
Received on Wednesday, 20 October 2010 16:32:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:16 GMT