Re: Executing script-inserted external scripts in insertion order

Hallvord R. M. Steen wrote:
> On Thu, 21 Oct 2010 17:13:50 +0900, Adam Barth <w3c@adambarth.com>
> replied
> to Henri Sivonen:
> 
> >> Could you elaborate on why you chose infinity of ordered queues
> >> instead
> >> of one ordered queue? It seems to me that the Zero One Infinity
> >> rule
> >> leaves one as another reasonable number of ordered queues.
> >
> > Because this mechanism is explicit. Instead of having a secret queue
> > that most folks won't know is there and is subtly different in
> > different versions of browsers, it's clear what the author wants
> > from
> > this mechanism.
> 
> I see the point about explicity.

I think setting .async=false is pretty explicitly doing *something*.

> Setting '.async=false' seems pretty
> understandable to authors who understand what <script async> does, but
> if
> I try thinking as an author it's not really obvious what script to set
> async on. Async=false would mean "make sure any scripts added to the
> DOM
> before this one have executed before trying to execute this script",
> or
> "make sure this script is executed before those I add afterwards"?

Yeah, the author would have to know what .async=false means when using it.

> I actually like your document.executeScrips() proposal, it takes the
> use
> case LABjs demonstrates a demand for and ensures there is a built-in
> API
> that's easy enough sites can use it without requiring helper scripts.
> The
> counter-argument is feature creep..

Having a script execution mechanism that's not tied to HTMLScriptElement nodes means that over time we'd potentially have to duplicate everything that now assumes HTMLScriptElement nodes including:
 * document.currentScript (so far a Gecko-only thing with a proposal posted to WHATWG)
 * various event handlers for tracking the script
 * setting the script type (The current executeScript() proposal seems to be limited to "text/javascript" scripts. I realize that some people may consider this a feature rather than a bug.)

> Regarding the issues with the proposed use of async, would it help if
> we
> moved the feature detection away from the proposed
> "document.createElement('script').async==true", for example to
> HTMLScriptElement.defaultAsync ? Would it help if we specified @async
> as
> an enumerated attribute with values "true" and "false"? Example code
> to
> add a script through DOM and mark it as ordered
> 
> var orderedScript=document.createElement('script');
> orderedScript.src='foo.js';
> if( HTMLScriptElement.defaultAsync ){
> orderedScript.setAttribute('async', 'false');
> }

That could work. However, I doubt authors appreciate this .foo vs. .defaultFoo thing. See http://html5doctor.com/html5-simplequiz-3-how-to-mute-a-video/#comments

Also, why bother with having .defaultAsync? If the definition of .async changed from what has been shipped in Firefox 3.6, why would anyone want to use .defaultAsync? Wouldn't .defaultAsync be there just "for completeness" as a matter of principle of having IDL properties for all attributes specified in the language?

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

Received on Tuesday, 26 October 2010 07:08:28 UTC