WHATWG Wiki - User contributions [en]

Script Execution Control

2012-09-12T15:17:12Z

Getify: updating link to spec location for discussion about the "true preloading" technique.

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

'''The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).'''

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

<del>2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.</del>

[[User:Getify|Getify]] 15:24, 14 February 2011 (UTC)

2. This proposal requires changes from IE to achieve full-compat. As IE is known to have a much slower release timeline, and IE9 is now feature-complete and nearing a full release soon, the likelihood is that this current IE cycle has been missed for any such changes. That means full-compat would probably be at best 1-2 years from now.

[[User:Getify|Getify]] 15:27, 14 February 2011 (UTC)

3. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

4. Run-away memory usage (see [[Script_Execution_Control#Limitations_2|2.2.1.3]])

5. Doesn't support inline script "preloading" (see [[Script_Execution_Control#Limitations_2|2.2.1.2]])

6. This proposal doesn't specify fetch error handling. onerror is currently not fired on scripts which are not in a document.

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/the-script-element.html#script-processing-src-prepare HTML Spec, 4.3.1, 'Preparing a script']

Specifically, in step 14 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

'''The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.'''

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

3. All the preloading proposals suffer a potential for run-away memory consumption if a script misbehaves and causes a bunch of "preloaded" scripts that it abandons and never attaches to the page to execute. The browser would have to hold on to that memory for the lifetime of the page, assuming that one might be used at some later time on the page.

This particular proposal makes this a little bit more likely since it's easier (automatic, rather than opt-in) to make the mistake.

Two suggestions for how to address:

a) implement some content-uniqueness in-memory cache which only keeps one copy of each unique set of resource content in memory, to prevent needless duplication. the algorithm for how to do this correctly is probably quite complicated to actually do.

b) implement a cap on the number of scripts that will be preloaded, for instance at 200 or 500. If the cap is high enough, almost all normal sites which will use preloading will never need that many scripts waiting in a preloading queue. And the run-away sites will be prevented from consuming more than that cap. Any script preload requests above the cap will simply sit and wait for a preloading slot to become available. The resolution is to simply start executing some scripts by adding them to the page, thereby freeing up more preloading slots.

* a sub-idea for this suggestion is to have, instead of a hard-cap, a soft-cap, where if it's hit, a user-prompt happens (like the "long-running JavaScript" prompt), where a user can decide if the browser should be allowed to keep going with preloading or be capped.

4. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

5. This proposal doesn't specify fetch error handling. onerror is currently not fired on scripts which are not in a document.

=== Proposal 3 (Glenn Maynard) ===

This proposal keeps changes to script preparation and execution to a bare minimum. Changes are described in terms of actual spec changes, to describe its behavior clearly and to show how it fits in with the existing spec. Briefly, a "noexecute" attribute is added to block execution of the script, which is cleared to reenable execution. More precisely:

* Add the following attribute definition:
The noexecute attribute is a boolean attribute that indicates that the
script should not be executed.
* Add the following flag definition:
The fifth is a flag indicating that a script is "pending-execution". Initially,
script elements must have this flag unset. This flag is used to trigger execution
if execution was deferred due to a noexecute attribute.
* Add the following to "execute a script block", before "1. Initialize the script block's source as follows":
0. If the element has a "noexecute" attribute, set the "pending-execution" flag
and abort these steps.
* For each part of step 15 "Then, the first ..." of "prepare a script", the noexecute attribute being set implies the async attribute is also set, eg. "... and the element has neither an async nor a noexecute attribute". That is, noexecute implies async.
* If the "noexecute" attribute is changed, and the "pending-execution" flag is set, clear the "pending-execution" flag and queue a task to execute the script block.
* When the fetch algorithm completes without error, fire a simple event named "fetch" at the element.

Notes:

* Invariant: if the "pending-execution" flag is set, the "already started" flag is also set.
* The attribute name "noexecute" reflects its behavior more clearly than "preload". API naming should reflect what the API does, not name a use case.
* For feature detection: typeof(document.createElement("script").noexecute) == "boolean".
* Scripts are still only executed once, regulated by the "already started" flag.
* The "pending-execution" flag is not copied to clones, so a script that has run "prepare a script" will run again in a clone.
* The onfetch event is orthogonal to the rest, and should be fired whether or not noexecute is set. It's symmetric with onerror. (onreadystatechange is not recommended; it clashes with existing IE behavior. IE fires onreadystatechange with "loaded" for both success and error, making it hard to tell whether the load actually succeeded.) The "fetch" event isn't a new concept, it's simply the "load" of Progress Events-like contexts; a different name is used because script events already have a "load" event with a different meaning.
* <script noexecute> is comparable to <style disabled>, which can also be used for advance resource loading.
* The fetch event should be fired at most once, if the fetch algorithm finishes without error. That's not the top of "execute a script block" since that can be executed more than once. I'm not sure what the correct spec mechanism is to describe this.
* This could be extended slightly to support inline scripts, with additional modifications to "prepare a script" step 15.

Advantages:

* Feedback is that this approach is more likely to see implementation in Gecko, and it avoids potential issues related to fetching resources when not added to a document without needing additional resource limiting.
* DOM event consistency is maintained by not requiring elements be kept out of the document while loading. Fetch and error events can be captured, so event delegation continues to work consistently.
* Fetch error handling (DNS errors, 404 errors) is handled with no changes to current behavior.
* In addition to programmatic preloading, scripts can also be preloaded in markup and later activated by scripts.

--[[Talk:Script_Execution_Control#Discussion_for_2.3_Proposal|discussion]]

==== Limitations ====
1. From the markup perspective, this approach does not have graceful degradation, since in browsers without `noexecute` support, such scripts would execute right away, even though told not to. Markup doesn't provide the ability to feature-detect.
* [[Talk:Script_Execution_Control#Discussion_for_2.3_Proposal|discussion]]

2. As stated in support sections for the other proposals, this proposal requires a fundamental change to how IE operates. As such, the feasibility of getting such a change into a released version of IE is, at best 18-24 months down the road, and that's if IE even agreed to change their existing preloading behavior.
* [[Talk:Script_Execution_Control#Discussion_for_2.3_Proposal|discussion]]

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Talk:Script Execution Control

2011-03-06T19:33:41Z

Getify: further discussions over proposal 2.3

=== Discussion for [[Script_Execution_Control#Limitations_2|2.2.1.4 Limitations]] ===

<blockquote style="background-color:#ddd;">
Events (eg. onload) fired on preloading script elements can not be captured by the document, because the node is not in the DOM tree during preloading.
</blockquote>

* true, but this seems like pretty inconsequential. no valid use-case has been presented where this type of event handling would be superior than element-binding event handling, for the use-cases under consideration. [[User:Getify|Getify]] 23:31, 3 March 2011 (UTC)

* This breaks from a fairly consistent API design across DOM elements; that's not inconsequential. The use cases are the same as any event capturing (eg. event delegation, logging). [[User:Glenn|Glenn]]

* But almost every script loader I've ever seen or heard of uses direct script element event binding, not DOM event propagation, to listen for "onload" or "onreadystatechange". I'm only saying that it's trivial because this is not how script loaders do it, and so it's not a necessary use-case for the "preloading" that script loaders like LABjs or ControlJS want to do. What you're suggesting *could* have validity as extra benefit, but it's unfair to label it as a limitation or detraction from these 2 proposals, because in all fairness, noone's actually doing that now with any of the script load events. Just write up your third proposal, and include DOM event propagation as an additional benefit. [[User:Getify|Getify]] 19:19, 4 March 2011 (UTC)

* We're lucky enough to have relative consistency across the DOM API in being able to capture events. Being able to capture onerror at the document to globally receive all errors is extremely useful, for example. Reducing this consistency is not a trivial issue. [[User:Glenn|Glenn]]

=== Discussion for [[Script_Execution_Control#Proposal_3_.28Glenn_Maynard.29|2.3 Proposal]] ===

<blockquote style="background-color:#ddd;">
Feedback is that this approach is more likely to see implementation in Gecko, and it avoids potential issues related to fetching resources when not added to a document without needing additional resource limiting.
</blockquote>

* Not sure if this is a fully accurate statement, based on the WHATWG thread. Boris' most recent comments indicate perhaps the opposite. [[User:Getify|Getify]] 23:53, 4 March 2011 (UTC)
* I'll leave him to comment for himself. [[User:Glenn|Glenn]]

<blockquote style="background-color:#ddd;">
Fetch error handling (DNS errors, 404 errors) is handled with no changes to current behavior.
</blockquote>

* There's lots of fetch error conditions not currently handled consistently cross-browser by `onerror`, like 403's and 500's for instance. The error mechanism is fundamentally broken/under-specified when it comes to loading/network errors. So, citing a broken/under-implemented mechanism as support for this proposal is rather moot. [[User:Getify|Getify]] 23:53, 4 March 2011 (UTC)
* Are you proposing that the onerror event for script be dropped? If not, what exactly are you proposing? This is a contrived argument against a straightforward benefit: error handling is clearly defined under this proposal. [[User:Glenn|Glenn]]
* I'm not proposing it be dropped (right now). I'm simply asserting that because it's current implementation specifically for catching *network* loading errors is quite incomplete (only catches 1 error code -- 404 -- consistently cross-browser, out of a dozen or more other load errors that can and do happen), for preloading specifically, `onerror` won't be much help, since all preloading errors would only be loading errors. Since `onerror` is grossly under-implemented for network errors, it's not really a strong supporting case that your proposal preserves such an impractical mechanism. As the author of a wide-spread general script loader library (LABjs), I can say that `onerror` incompleteness and inconsistency cross-browser makes it totally unusable in a real world scenario (what good is a script loader 'error-detection' API that can only detect a small subset of the possible errors?). [[User:Getify|Getify]] 19:33, 6 March 2011 (UTC)
* Now, if you're ALSO proposing that `onerror` be completely fixed so it handles all types of network errors, and you have explored the feasibility of how all browsers can actually detect such errors given peculiarities of how the loading mechanism deals with the HTTP request stack, and you're going to clearly spell out all those semantics and details, fine. But your proposal just rests some laurels on "look, it's supports `onerror` handling", and my assertion is that `onerror` is pretty lame at the current time. I'd much rather attack the problems with `onerror` (or rather, just general load-error-detection) on script elements in a completely separate proposal cycle, one which I may very well suggest that `onerror` just be dropped altogether in favor of a new and more reliable mechanism. [[User:Getify|Getify]] 19:33, 6 March 2011 (UTC)

<blockquote style="background-color:#ddd;">
In addition to programmatic preloading, scripts can also be preloaded in markup and later activated by scripts.
</blockquote>

* Again, noone has yet expressed any serious use-cases for how that would be practical or more useful compared to programmatic preloading. Early in the WHATWG thread it was brought up, and never really went anywhere. Since you'd have to have some "script loader"-like logic to inspect the DOM for preloaded-and-waiting scripts and execute them in the proper order anyway, why not just have only a script loader? No benefit has been shown to having these script elements in the parser markup rather than programmatically injected. Optimizing the process for how all script loaders currently work is generally not a bad appraoch, so I'm not sure why introducing unprecedented markup-driven preloading is useful. [[User:Getify|Getify]] 23:53, 4 March 2011 (UTC)
* This is obvious: you can put dependent scripts in markup in the traditional way, allow them to be loaded normally on browsers that don't support noexecute, and execute them on demand on ones that do. [[User:Glenn|Glenn]]
* No, it's not obvious, nor is it valid. Your argument is like saying that it'd be ok if the <link rel=prefetch> tag was to go ahead and execute scripts, that this would be ok. "Preloading" as a use-case is not just about early (vs. late) loading/execution of a script, it's specifically about separating loading from execution (aka, preventing auto-execution), and deferring until a later, controlled time, the execution of that prior loaded resource. The markup use-case does NOT degrade gracefully at all for this purpose, because I as an author have no way to guarantee that the script doesn't execute right away. If I'm trying to do "preloading", it's because I have a good reason for it NOT to execute right then. [[User:Getify|Getify]] 19:33, 6 March 2011 (UTC)
*For instance, say I want to preload 3 different calendar widget scripts, but based on user actions, I only want one to be executed, whenever they click on some control. I certainly can't tolerate, nor is that graceful degradation, if in non-supporting browsers, all 3 scripts just automatically execute. The only sensible and practical way to handle browsers that don't support official preloading is to use the fallback "cache preloading" hacks (like the fake mime-type, the <object>, or the Image). This *has* to be done via script logic. Therefore, my assertion, the main use-case for preloading is NOT served, nor gracefully degraded, by markup driven preloading. [[User:Getify|Getify]] 19:33, 6 March 2011 (UTC)

<blockquote style="background-color:#ddd;">
Limitations

From the markup perspective, this approach does not have graceful degradation, since in browsers without `noexecute` support, such scripts would execute right away, even though told not to. Markup doesn't provide the ability to feature-detect.
</blockquote>

* Since the markup use-case doesn't degrade well, and markup doesn't provide feature-detection to handle such lack of support in an alternate way, the markup use-case for preloading is moot and unuseable in practice. This is further reasoning for why "preloading" should only be controlled by a script loader injecting the script elements dynamically, which the other proposals handle quite well. [[User:Getify|Getify]] 23:53, 4 March 2011 (UTC)
* The markup case degrades straightforwardly, loading the scripts normally and in order. Typically you'd also combine this with defer, for browsers that support it. [[User:Glenn|Glenn]]
* You're focusing on one small niche usage for "preloading", and missing the main use-case, which is to completely separate loading from execution, and programatically control execution later. The degradation to non-supporting browsers in the markup case would completely violate that fundamental assumption, and, as described just above, could cause script code to execute that the author does not want to execute. This is not graceful degradation. It's utter failure of the main use-case. The markup use-case for "preloading" is weak in and of itself, and it totally does not degrade for the main intended uses of "preloading" that precipitated these proposals in the first place. [[User:Getify|Getify]] 19:33, 6 March 2011 (UTC)

<blockquote style="background-color:#ddd;">
As stated in support sections for the other proposals, this proposal requires a fundamental change to how IE operates. As such, the feasibility of getting such a change into a released version of IE is, at best 18-24 months down the road, and that's if IE even agreed to change their existing preloading behavior.
</blockquote>

* IE may rightly say that they already support preloading, and willfully violate such a proposal (even if spec'd), which will continue to keep us in non-compat browser forking instead of convergent compat. [[User:Getify|Getify]] 23:53, 4 March 2011 (UTC)
* They may say a lot of things. You stretching the "IE card" very thin. [[User:Glenn|Glenn]]
* I don't feel that the pragmatism of keeping IE's perspective (and ability and willingness to change LONG-HELD precedent in their browser) is "stretching"... I think it's wise and prudent compromise process. But I suppose we'll just have to disagree on that. [[User:Getify|Getify]] 19:33, 6 March 2011 (UTC)
* And I say "compromise" intentionally, because I actually prefer Nicholas' current (v2.1) proposal to mine... except for the fact that I think it has much less chance of finding compat across all browsers any time soon. I'm making the compromises in my proposal based on the idea that it's better to have a mechanism that's not quite ideal but works, if IE and all other browsers can agree, than to have a mechanism that's perfectly ideal and semantic but which will be rejected by one or more browser vendors. You on the other hand seem to dismiss outright the validity of considering IE's perspective on this issue. [[User:Getify|Getify]] 19:33, 6 March 2011 (UTC)

Script Execution Control

2011-03-04T23:56:33Z

Getify: adding limitations for proposal 3, as well as links to discussion

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

'''The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).'''

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

<del>2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.</del>

[[User:Getify|Getify]] 15:24, 14 February 2011 (UTC)

2. This proposal requires changes from IE to achieve full-compat. As IE is known to have a much slower release timeline, and IE9 is now feature-complete and nearing a full release soon, the likelihood is that this current IE cycle has been missed for any such changes. That means full-compat would probably be at best 1-2 years from now.

[[User:Getify|Getify]] 15:27, 14 February 2011 (UTC)

3. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

4. Run-away memory usage (see [[Script_Execution_Control#Limitations_2|2.2.1.3]])

5. Doesn't support inline script "preloading" (see [[Script_Execution_Control#Limitations_2|2.2.1.2]])

6. This proposal doesn't specify fetch error handling. onerror is currently not fired on scripts which are not in a document.

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

'''The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.'''

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

3. All the preloading proposals suffer a potential for run-away memory consumption if a script misbehaves and causes a bunch of "preloaded" scripts that it abandons and never attaches to the page to execute. The browser would have to hold on to that memory for the lifetime of the page, assuming that one might be used at some later time on the page.

This particular proposal makes this a little bit more likely since it's easier (automatic, rather than opt-in) to make the mistake.

Two suggestions for how to address:

a) implement some content-uniqueness in-memory cache which only keeps one copy of each unique set of resource content in memory, to prevent needless duplication. the algorithm for how to do this correctly is probably quite complicated to actually do.

b) implement a cap on the number of scripts that will be preloaded, for instance at 200 or 500. If the cap is high enough, almost all normal sites which will use preloading will never need that many scripts waiting in a preloading queue. And the run-away sites will be prevented from consuming more than that cap. Any script preload requests above the cap will simply sit and wait for a preloading slot to become available. The resolution is to simply start executing some scripts by adding them to the page, thereby freeing up more preloading slots.

* a sub-idea for this suggestion is to have, instead of a hard-cap, a soft-cap, where if it's hit, a user-prompt happens (like the "long-running JavaScript" prompt), where a user can decide if the browser should be allowed to keep going with preloading or be capped.

4. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

5. This proposal doesn't specify fetch error handling. onerror is currently not fired on scripts which are not in a document.

=== Proposal 3 (Glenn Maynard) ===

This proposal keeps changes to script preparation and execution to a bare minimum. Changes are described in terms of actual spec changes, to describe its behavior clearly and to show how it fits in with the existing spec. Briefly, a "noexecute" attribute is added to block execution of the script, which is cleared to reenable execution. More precisely:

* Add the following attribute definition:
The noexecute attribute is a boolean attribute that indicates that the
script should not be executed.
* Add the following flag definition:
The fifth is a flag indicating that a script is "pending-execution". Initially,
script elements must have this flag unset. This flag is used to trigger execution
if execution was deferred due to a noexecute attribute.
* Add the following to "execute a script block", before "1. Initialize the script block's source as follows":
0. If the element has a "noexecute" attribute, set the "pending-execution" flag
and abort these steps.
* For each part of step 15 "Then, the first ..." of "prepare a script", the noexecute attribute being set implies the async attribute is also set, eg. "... and the element has neither an async nor a noexecute attribute". That is, noexecute implies async.
* If the "noexecute" attribute is changed, and the "pending-execution" flag is set, clear the "pending-execution" flag and queue a task to execute the script block.
* When the fetch algorithm completes without error, fire a simple event named "fetch" at the element.

Notes:

* Invariant: if the "pending-execution" flag is set, the "already started" flag is also set.
* The attribute name "noexecute" reflects its behavior more clearly than "preload". API naming should reflect what the API does, not name a use case.
* For feature detection: typeof(document.createElement("script").noexecute) == "boolean".
* Scripts are still only executed once, regulated by the "already started" flag.
* The "pending-execution" flag is not copied to clones, so a script that has run "prepare a script" will run again in a clone.
* The onfetch event is orthogonal to the rest, and should be fired whether or not noexecute is set. It's symmetric with onerror. (onreadystatechange is not recommended; it clashes with existing IE behavior. IE fires onreadystatechange with "loaded" for both success and error, making it hard to tell whether the load actually succeeded.) The "fetch" event isn't a new concept, it's simply the "load" of Progress Events-like contexts; a different name is used because script events already have a "load" event with a different meaning.
* <script noexecute> is comparable to <style disabled>, which can also be used for advance resource loading.
* The fetch event should be fired at most once, if the fetch algorithm finishes without error. That's not the top of "execute a script block" since that can be executed more than once. I'm not sure what the correct spec mechanism is to describe this.
* This could be extended slightly to support inline scripts, with additional modifications to "prepare a script" step 15.

Advantages:

* Feedback is that this approach is more likely to see implementation in Gecko, and it avoids potential issues related to fetching resources when not added to a document without needing additional resource limiting.
* DOM event consistency is maintained by not requiring elements be kept out of the document while loading. Fetch and error events can be captured, so event delegation continues to work consistently.
* Fetch error handling (DNS errors, 404 errors) is handled with no changes to current behavior.
* In addition to programmatic preloading, scripts can also be preloaded in markup and later activated by scripts.

--[[Talk:Script_Execution_Control#Discussion_for_2.3_Proposal|discussion]]

==== Limitations ====
1. From the markup perspective, this approach does not have graceful degradation, since in browsers without `noexecute` support, such scripts would execute right away, even though told not to. Markup doesn't provide the ability to feature-detect.
* [[Talk:Script_Execution_Control#Discussion_for_2.3_Proposal|discussion]]

2. As stated in support sections for the other proposals, this proposal requires a fundamental change to how IE operates. As such, the feasibility of getting such a change into a released version of IE is, at best 18-24 months down the road, and that's if IE even agreed to change their existing preloading behavior.
* [[Talk:Script_Execution_Control#Discussion_for_2.3_Proposal|discussion]]

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Talk:Script Execution Control

2011-03-04T23:53:56Z

Getify: adding Discussion for 2.3

Script Execution Control

2011-03-04T19:33:36Z

Getify: /* Limitations */

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

'''The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).'''

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

<del>2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.</del>

[[User:Getify|Getify]] 15:24, 14 February 2011 (UTC)

2. This proposal requires changes from IE to achieve full-compat. As IE is known to have a much slower release timeline, and IE9 is now feature-complete and nearing a full release soon, the likelihood is that this current IE cycle has been missed for any such changes. That means full-compat would probably be at best 1-2 years from now.

[[User:Getify|Getify]] 15:27, 14 February 2011 (UTC)

3. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

4. Run-away memory usage (see [[Script_Execution_Control#Limitations_2|2.2.1.3]])

5. Doesn't support inline script "preloading" (see [[Script_Execution_Control#Limitations_2|2.2.1.2]])

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

'''The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.'''

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

3. All the preloading proposals suffer a potential for run-away memory consumption if a script misbehaves and causes a bunch of "preloaded" scripts that it abandons and never attaches to the page to execute. The browser would have to hold on to that memory for the lifetime of the page, assuming that one might be used at some later time on the page.

This particular proposal makes this a little bit more likely since it's easier (automatic, rather than opt-in) to make the mistake.

Two suggestions for how to address:

a) implement some content-uniqueness in-memory cache which only keeps one copy of each unique set of resource content in memory, to prevent needless duplication. the algorithm for how to do this correctly is probably quite complicated to actually do.

b) implement a cap on the number of scripts that will be preloaded, for instance at 200 or 500. If the cap is high enough, almost all normal sites which will use preloading will never need that many scripts waiting in a preloading queue. And the run-away sites will be prevented from consuming more than that cap. Any script preload requests above the cap will simply sit and wait for a preloading slot to become available. The resolution is to simply start executing some scripts by adding them to the page, thereby freeing up more preloading slots.

* a sub-idea for this suggestion is to have, instead of a hard-cap, a soft-cap, where if it's hit, a user-prompt happens (like the "long-running JavaScript" prompt), where a user can decide if the browser should be allowed to keep going with preloading or be capped.

4. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Script Execution Control

2011-03-04T19:33:02Z

Getify: /* Limitations */

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

'''The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).'''

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

<del>2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.</del>

[[User:Getify|Getify]] 15:24, 14 February 2011 (UTC)

2. This proposal requires changes from IE to achieve full-compat. As IE is known to have a much slower release timeline, and IE9 is now feature-complete and nearing a full release soon, the likelihood is that this current IE cycle has been missed for any such changes. That means full-compat would probably be at best 1-2 years from now.

[[User:Getify|Getify]] 15:27, 14 February 2011 (UTC)

3. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

4. Run-away memory usage (see [[Script_Execution_Control#Limitations_2|2.2.1.3]])

5. Doesn't support inline script "preloading" (see [[Script_Execution_Control#Limitations_2|2.2.1.2]])

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

'''The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.'''

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

3. All the preloading proposals suffer a potential for run-away memory consumption if a script misbehaves and causes a bunch of "preloaded" scripts that it abandons and never attaches to the page to execute. The browser would have to hold on to that memory for the lifetime of the page, assuming that one might be used at some later time on the page.

This particular proposal makes this a little bit more likely since it's easier (automatic, rather than opt-in) to make the mistake.

Two suggestions for how to address:

a) implement some content-uniqueness in-memory cache which only keeps one copy of each unique set of resource content in memory, to prevent needless duplication. the algorithm for how to do this correctly is probably quite complicated to actually do.

b) implement a cap on the number of scripts that will be preloaded, for instance at 200 or 500. If the cap is high enough, almost all normal sites which will use preloading will never need that many scripts waiting in a preloading queue. And the run-away sites will be prevented from consuming more than that cap. Any script preload requests above the cap will simply sit and wait for a preloading slot to become available. The resolution is to simply start executing some scripts by adding them to the page, thereby freeing up more preloading slots.

-- a sub-idea for this suggestion is to have, instead of a hard-cap, a soft-cap, where if it's hit, a user-prompt happens (like the "long-running JavaScript" prompt), where a user can decide if the browser should be allowed to keep going with preloading or be capped.

4. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Script Execution Control

2011-03-04T19:30:23Z

Getify: adding cross-link to other proposal's limitation description on not supporting inline script "preloading"

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

'''The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).'''

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

<del>2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.</del>

[[User:Getify|Getify]] 15:24, 14 February 2011 (UTC)

2. This proposal requires changes from IE to achieve full-compat. As IE is known to have a much slower release timeline, and IE9 is now feature-complete and nearing a full release soon, the likelihood is that this current IE cycle has been missed for any such changes. That means full-compat would probably be at best 1-2 years from now.

[[User:Getify|Getify]] 15:27, 14 February 2011 (UTC)

3. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

4. Run-away memory usage (see [[Script_Execution_Control#Limitations_2|2.2.1.3]])

5. Doesn't support inline script "preloading" (see [[Script_Execution_Control#Limitations_2|2.2.1.2]])

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

'''The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.'''

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

3. All the preloading proposals suffer a potential for run-away memory consumption if a script misbehaves and causes a bunch of "preloaded" scripts that it abandons and never attaches to the page to execute. The browser would have to hold on to that memory for the lifetime of the page, assuming that one might be used at some later time on the page.

This particular proposal makes this a little bit more likely since it's easier (automatic, rather than opt-in) to make the mistake.

Two suggestions for how to address:
a) implement some content-uniqueness in-memory cache which only keeps one copy of each unique set of resource content in memory, to prevent needless duplication. the algorithm for how to do this correctly is probably quite complicated to actually do.

b) implement a cap on the number of scripts that will be preloaded, for instance at 200 or 500. If the cap is high enough, almost all normal sites which will use preloading will never need that many scripts waiting in a preloading queue. And the run-away sites will be prevented from consuming more than that cap. Any script preload requests above the cap will simply sit and wait for a preloading slot to become available. The resolution is to simply start executing some scripts by adding them to the page, thereby freeing up more preloading slots.

-- a sub-idea for this suggestion is to have, instead of a hard-cap, a soft-cap, where if it's hit, a user-prompt happens (like the "long-running JavaScript" prompt), where a user can decide if the browser should be allowed to keep going with preloading or be capped.

4. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Script Execution Control

2011-03-04T19:28:08Z

Getify: adding cross-link to other proposal's limitation description on "run-away memory"

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

'''The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).'''

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

<del>2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.</del>

[[User:Getify|Getify]] 15:24, 14 February 2011 (UTC)

2. This proposal requires changes from IE to achieve full-compat. As IE is known to have a much slower release timeline, and IE9 is now feature-complete and nearing a full release soon, the likelihood is that this current IE cycle has been missed for any such changes. That means full-compat would probably be at best 1-2 years from now.

[[User:Getify|Getify]] 15:27, 14 February 2011 (UTC)

3. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

4. Run-away memory usage (see [[Script_Execution_Control#Limitations_2|2.2.1.3]])

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

'''The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.'''

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

3. All the preloading proposals suffer a potential for run-away memory consumption if a script misbehaves and causes a bunch of "preloaded" scripts that it abandons and never attaches to the page to execute. The browser would have to hold on to that memory for the lifetime of the page, assuming that one might be used at some later time on the page.

This particular proposal makes this a little bit more likely since it's easier (automatic, rather than opt-in) to make the mistake.

Two suggestions for how to address:
a) implement some content-uniqueness in-memory cache which only keeps one copy of each unique set of resource content in memory, to prevent needless duplication. the algorithm for how to do this correctly is probably quite complicated to actually do.

b) implement a cap on the number of scripts that will be preloaded, for instance at 200 or 500. If the cap is high enough, almost all normal sites which will use preloading will never need that many scripts waiting in a preloading queue. And the run-away sites will be prevented from consuming more than that cap. Any script preload requests above the cap will simply sit and wait for a preloading slot to become available. The resolution is to simply start executing some scripts by adding them to the page, thereby freeing up more preloading slots.

-- a sub-idea for this suggestion is to have, instead of a hard-cap, a soft-cap, where if it's hit, a user-prompt happens (like the "long-running JavaScript" prompt), where a user can decide if the browser should be allowed to keep going with preloading or be capped.

4. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Script Execution Control

2011-03-04T19:25:16Z

Getify: updating link

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

'''The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).'''

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

<del>2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.</del>

[[User:Getify|Getify]] 15:24, 14 February 2011 (UTC)

2. This proposal requires changes from IE to achieve full-compat. As IE is known to have a much slower release timeline, and IE9 is now feature-complete and nearing a full release soon, the likelihood is that this current IE cycle has been missed for any such changes. That means full-compat would probably be at best 1-2 years from now.

[[User:Getify|Getify]] 15:27, 14 February 2011 (UTC)

3. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

'''The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.'''

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

3. All the preloading proposals suffer a potential for run-away memory consumption if a script misbehaves and causes a bunch of "preloaded" scripts that it abandons and never attaches to the page to execute. The browser would have to hold on to that memory for the lifetime of the page, assuming that one might be used at some later time on the page.

This particular proposal makes this a little bit more likely since it's easier (automatic, rather than opt-in) to make the mistake.

Two suggestions for how to address:
a) implement some content-uniqueness in-memory cache which only keeps one copy of each unique set of resource content in memory, to prevent needless duplication. the algorithm for how to do this correctly is probably quite complicated to actually do.

b) implement a cap on the number of scripts that will be preloaded, for instance at 200 or 500. If the cap is high enough, almost all normal sites which will use preloading will never need that many scripts waiting in a preloading queue. And the run-away sites will be prevented from consuming more than that cap. Any script preload requests above the cap will simply sit and wait for a preloading slot to become available. The resolution is to simply start executing some scripts by adding them to the page, thereby freeing up more preloading slots.

-- a sub-idea for this suggestion is to have, instead of a hard-cap, a soft-cap, where if it's hit, a user-prompt happens (like the "long-running JavaScript" prompt), where a user can decide if the browser should be allowed to keep going with preloading or be capped.

4. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Script Execution Control

2011-03-04T19:24:11Z

Getify: updating link

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

'''The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).'''

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

<del>2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.</del>

[[User:Getify|Getify]] 15:24, 14 February 2011 (UTC)

2. This proposal requires changes from IE to achieve full-compat. As IE is known to have a much slower release timeline, and IE9 is now feature-complete and nearing a full release soon, the likelihood is that this current IE cycle has been missed for any such changes. That means full-compat would probably be at best 1-2 years from now.

[[User:Getify|Getify]] 15:27, 14 February 2011 (UTC)

3. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

'''The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.'''

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

3. All the preloading proposals suffer a potential for run-away memory consumption if a script misbehaves and causes a bunch of "preloaded" scripts that it abandons and never attaches to the page to execute. The browser would have to hold on to that memory for the lifetime of the page, assuming that one might be used at some later time on the page.

This particular proposal makes this a little bit more likely since it's easier (automatic, rather than opt-in) to make the mistake.

Two suggestions for how to address:
a) implement some content-uniqueness in-memory cache which only keeps one copy of each unique set of resource content in memory, to prevent needless duplication. the algorithm for how to do this correctly is probably quite complicated to actually do.

b) implement a cap on the number of scripts that will be preloaded, for instance at 200 or 500. If the cap is high enough, almost all normal sites which will use preloading will never need that many scripts waiting in a preloading queue. And the run-away sites will be prevented from consuming more than that cap. Any script preload requests above the cap will simply sit and wait for a preloading slot to become available. The resolution is to simply start executing some scripts by adding them to the page, thereby freeing up more preloading slots.

-- a sub-idea for this suggestion is to have, instead of a hard-cap, a soft-cap, where if it's hit, a user-prompt happens (like the "long-running JavaScript" prompt), where a user can decide if the browser should be allowed to keep going with preloading or be capped.

4. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control]])

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Talk:Script Execution Control

2011-03-04T19:23:26Z

Getify: /* Discussion for 2.2.1.4 Limitations: */

Script Execution Control

2011-03-04T19:21:05Z

Getify: moving discussion to talk page

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

'''The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).'''

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

<del>2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.</del>

[[User:Getify|Getify]] 15:24, 14 February 2011 (UTC)

2. This proposal requires changes from IE to achieve full-compat. As IE is known to have a much slower release timeline, and IE9 is now feature-complete and nearing a full release soon, the likelihood is that this current IE cycle has been missed for any such changes. That means full-compat would probably be at best 1-2 years from now.

[[User:Getify|Getify]] 15:27, 14 February 2011 (UTC)

3. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control]])

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

'''The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.'''

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

3. All the preloading proposals suffer a potential for run-away memory consumption if a script misbehaves and causes a bunch of "preloaded" scripts that it abandons and never attaches to the page to execute. The browser would have to hold on to that memory for the lifetime of the page, assuming that one might be used at some later time on the page.

This particular proposal makes this a little bit more likely since it's easier (automatic, rather than opt-in) to make the mistake.

Two suggestions for how to address:
a) implement some content-uniqueness in-memory cache which only keeps one copy of each unique set of resource content in memory, to prevent needless duplication. the algorithm for how to do this correctly is probably quite complicated to actually do.

b) implement a cap on the number of scripts that will be preloaded, for instance at 200 or 500. If the cap is high enough, almost all normal sites which will use preloading will never need that many scripts waiting in a preloading queue. And the run-away sites will be prevented from consuming more than that cap. Any script preload requests above the cap will simply sit and wait for a preloading slot to become available. The resolution is to simply start executing some scripts by adding them to the page, thereby freeing up more preloading slots.

-- a sub-idea for this suggestion is to have, instead of a hard-cap, a soft-cap, where if it's hit, a user-prompt happens (like the "long-running JavaScript" prompt), where a user can decide if the browser should be allowed to keep going with preloading or be capped.

4. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control]])

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Script Execution Control

2011-03-04T19:20:29Z

Getify: moving discussion to talk page

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

'''The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).'''

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

<del>2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.</del>

[[User:Getify|Getify]] 15:24, 14 February 2011 (UTC)

2. This proposal requires changes from IE to achieve full-compat. As IE is known to have a much slower release timeline, and IE9 is now feature-complete and nearing a full release soon, the likelihood is that this current IE cycle has been missed for any such changes. That means full-compat would probably be at best 1-2 years from now.

[[User:Getify|Getify]] 15:27, 14 February 2011 (UTC)

3. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control]])

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

'''The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.'''

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

3. All the preloading proposals suffer a potential for run-away memory consumption if a script misbehaves and causes a bunch of "preloaded" scripts that it abandons and never attaches to the page to execute. The browser would have to hold on to that memory for the lifetime of the page, assuming that one might be used at some later time on the page.

This particular proposal makes this a little bit more likely since it's easier (automatic, rather than opt-in) to make the mistake.

Two suggestions for how to address:
a) implement some content-uniqueness in-memory cache which only keeps one copy of each unique set of resource content in memory, to prevent needless duplication. the algorithm for how to do this correctly is probably quite complicated to actually do.

b) implement a cap on the number of scripts that will be preloaded, for instance at 200 or 500. If the cap is high enough, almost all normal sites which will use preloading will never need that many scripts waiting in a preloading queue. And the run-away sites will be prevented from consuming more than that cap. Any script preload requests above the cap will simply sit and wait for a preloading slot to become available. The resolution is to simply start executing some scripts by adding them to the page, thereby freeing up more preloading slots.

-- a sub-idea for this suggestion is to have, instead of a hard-cap, a soft-cap, where if it's hit, a user-prompt happens (like the "long-running JavaScript" prompt), where a user can decide if the browser should be allowed to keep going with preloading or be capped.

4. Events (eg. onload) fired on preloading script elements can not be captured by the document, because the node is not in the DOM tree during preloading.
-- true, but this seems like pretty inconsequential. no valid use-case has been presented where this type of event handling would be superior than element-binding event handling, for the use-cases under consideration. [[User:Getify|Getify]] 23:30, 3 March 2011 (UTC)

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Talk:Script Execution Control

2011-03-04T19:19:04Z

Getify: moving discussion from the main page to here

=== Discussion for [[Script_Execution_Control#Limitations_2|2.2.1.4 Limitations]]: ===

<blockquote style="background-color:#ddd;">
Events (eg. onload) fired on preloading script elements can not be captured by the document, because the node is not in the DOM tree during preloading.
</blockquote>

* true, but this seems like pretty inconsequential. no valid use-case has been presented where this type of event handling would be superior than element-binding event handling, for the use-cases under consideration. [[User:Getify|Getify]] 23:31, 3 March 2011 (UTC)

* This breaks from a fairly consistent API design across DOM elements; that's not inconsequential. The use cases are the same as any event capturing (eg. event delegation, logging). [[User:Glenn|Glenn]]

* But almost every script loader I've ever seen or heard of uses direct script element event binding, not DOM event propagation, to listen for "onload" or "onreadystatechange". I'm only saying that it's trivial because this is not how script loaders do it, and so it's not a necessary use-case for the "preloading" that script loaders like LABjs or ControlJS want to do. What you're suggesting *could* have validity as extra benefit, but it's unfair to label it as a limitation or detraction from these 2 proposals, because in all fairness, noone's actually doing that now with any of the script load events. Just write up your third proposal, and include DOM event propagation as an additional benefit. [[User:Getify|Getify]] 19:19, 4 March 2011 (UTC)

Script Execution Control

2011-03-03T23:31:49Z

Getify: "events" limitation, and response

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

'''The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).'''

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

<del>2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.</del>

[[User:Getify|Getify]] 15:24, 14 February 2011 (UTC)

2. This proposal requires changes from IE to achieve full-compat. As IE is known to have a much slower release timeline, and IE9 is now feature-complete and nearing a full release soon, the likelihood is that this current IE cycle has been missed for any such changes. That means full-compat would probably be at best 1-2 years from now.

[[User:Getify|Getify]] 15:27, 14 February 2011 (UTC)

3. Events (eg. onload) fired on preloading script elements can not be captured by the document, because the node is not in the DOM tree during preloading.
-- true, but this seems like pretty inconsequential. no valid use-case has been presented where this type of event handling would be superior than element-binding event handling, for the use-cases under consideration. [[User:Getify|Getify]] 23:31, 3 March 2011 (UTC)

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

'''The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.'''

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

3. All the preloading proposals suffer a potential for run-away memory consumption if a script misbehaves and causes a bunch of "preloaded" scripts that it abandons and never attaches to the page to execute. The browser would have to hold on to that memory for the lifetime of the page, assuming that one might be used at some later time on the page.

This particular proposal makes this a little bit more likely since it's easier (automatic, rather than opt-in) to make the mistake.

Two suggestions for how to address:
a) implement some content-uniqueness in-memory cache which only keeps one copy of each unique set of resource content in memory, to prevent needless duplication. the algorithm for how to do this correctly is probably quite complicated to actually do.

b) implement a cap on the number of scripts that will be preloaded, for instance at 200 or 500. If the cap is high enough, almost all normal sites which will use preloading will never need that many scripts waiting in a preloading queue. And the run-away sites will be prevented from consuming more than that cap. Any script preload requests above the cap will simply sit and wait for a preloading slot to become available. The resolution is to simply start executing some scripts by adding them to the page, thereby freeing up more preloading slots.

-- a sub-idea for this suggestion is to have, instead of a hard-cap, a soft-cap, where if it's hit, a user-prompt happens (like the "long-running JavaScript" prompt), where a user can decide if the browser should be allowed to keep going with preloading or be capped.

4. Events (eg. onload) fired on preloading script elements can not be captured by the document, because the node is not in the DOM tree during preloading.
-- true, but this seems like pretty inconsequential. no valid use-case has been presented where this type of event handling would be superior than element-binding event handling, for the use-cases under consideration. [[User:Getify|Getify]] 23:30, 3 March 2011 (UTC)

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Script Execution Control

2011-03-03T23:30:12Z

Getify: response to "events" limitation

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

'''The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).'''

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

<del>2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.</del>

[[User:Getify|Getify]] 15:24, 14 February 2011 (UTC)

2. This proposal requires changes from IE to achieve full-compat. As IE is known to have a much slower release timeline, and IE9 is now feature-complete and nearing a full release soon, the likelihood is that this current IE cycle has been missed for any such changes. That means full-compat would probably be at best 1-2 years from now.

[[User:Getify|Getify]] 15:27, 14 February 2011 (UTC)

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

'''The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.'''

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

3. All the preloading proposals suffer a potential for run-away memory consumption if a script misbehaves and causes a bunch of "preloaded" scripts that it abandons and never attaches to the page to execute. The browser would have to hold on to that memory for the lifetime of the page, assuming that one might be used at some later time on the page.

This particular proposal makes this a little bit more likely since it's easier (automatic, rather than opt-in) to make the mistake.

Two suggestions for how to address:
a) implement some content-uniqueness in-memory cache which only keeps one copy of each unique set of resource content in memory, to prevent needless duplication. the algorithm for how to do this correctly is probably quite complicated to actually do.

b) implement a cap on the number of scripts that will be preloaded, for instance at 200 or 500. If the cap is high enough, almost all normal sites which will use preloading will never need that many scripts waiting in a preloading queue. And the run-away sites will be prevented from consuming more than that cap. Any script preload requests above the cap will simply sit and wait for a preloading slot to become available. The resolution is to simply start executing some scripts by adding them to the page, thereby freeing up more preloading slots.

-- a sub-idea for this suggestion is to have, instead of a hard-cap, a soft-cap, where if it's hit, a user-prompt happens (like the "long-running JavaScript" prompt), where a user can decide if the browser should be allowed to keep going with preloading or be capped.

4. Events (eg. onload) fired on preloading script elements can not be captured by the document, because the node is not in the DOM tree during preloading.
-- true, but this seems like pretty inconsequential. no valid use-case has been presented where this type of event handling would be superior than element-binding event handling, for the use-cases under consideration. [[User:Getify|Getify]] 23:30, 3 March 2011 (UTC)

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Script Execution Control

2011-03-03T22:33:52Z

Getify: /* Limitations */

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

'''The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).'''

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

<del>2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.</del>

[[User:Getify|Getify]] 15:24, 14 February 2011 (UTC)

2. This proposal requires changes from IE to achieve full-compat. As IE is known to have a much slower release timeline, and IE9 is now feature-complete and nearing a full release soon, the likelihood is that this current IE cycle has been missed for any such changes. That means full-compat would probably be at best 1-2 years from now.

[[User:Getify|Getify]] 15:27, 14 February 2011 (UTC)

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

'''The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.'''

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

3. All the preloading proposals suffer a potential for run-away memory consumption if a script misbehaves and causes a bunch of "preloaded" scripts that it abandons and never attaches to the page to execute. The browser would have to hold on to that memory for the lifetime of the page, assuming that one might be used at some later time on the page.

This particular proposal makes this a little bit more likely since it's easier (automatic, rather than opt-in) to make the mistake.

Two suggestions for how to address:
a) implement some content-uniqueness in-memory cache which only keeps one copy of each unique set of resource content in memory, to prevent needless duplication. the algorithm for how to do this correctly is probably quite complicated to actually do.

b) implement a cap on the number of scripts that will be preloaded, for instance at 200 or 500. If the cap is high enough, almost all normal sites which will use preloading will never need that many scripts waiting in a preloading queue. And the run-away sites will be prevented from consuming more than that cap. Any script preload requests above the cap will simply sit and wait for a preloading slot to become available. The resolution is to simply start executing some scripts by adding them to the page, thereby freeing up more preloading slots.

-- a sub-idea for this suggestion is to have, instead of a hard-cap, a soft-cap, where if it's hit, a user-prompt happens (like the "long-running JavaScript" prompt), where a user can decide if the browser should be allowed to keep going with preloading or be capped.

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Script Execution Control

2011-03-03T22:30:36Z

Getify: adding discussion of "run-away memory" issue

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

'''The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).'''

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

<del>2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.</del>

[[User:Getify|Getify]] 15:24, 14 February 2011 (UTC)

2. This proposal requires changes from IE to achieve full-compat. As IE is known to have a much slower release timeline, and IE9 is now feature-complete and nearing a full release soon, the likelihood is that this current IE cycle has been missed for any such changes. That means full-compat would probably be at best 1-2 years from now.

[[User:Getify|Getify]] 15:27, 14 February 2011 (UTC)

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

'''The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.'''

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

3. All the preloading proposals suffer a potential for run-away memory consumption if a script misbehaves and causes a bunch of "preloaded" scripts that it abandons and never attaches to the page to execute. The browser would have to hold on to that memory for the lifetime of the page, assuming that one might be used at some later time on the page.

This particular proposal makes this a little bit more likely since it's easier (automatic, rather than opt-in) to make the mistake.

Two suggestions for how to address:
a) implement some content-uniqueness in-memory cache which only keeps one copy of each unique set of resource content in memory, to prevent needless duplication. the algorithm for how to do this correctly is probably quite complicated to actually do.

b) implement a cap on the number of scripts that will be preloaded, for instance at 200 or 500. If the cap is high enough, almost all normal sites which will use preloading will never need that many scripts waiting in a preloading queue. And the run-away sites will be prevented from consuming more than that cap. Any script preload requests above the cap will simply sit and wait for a preloading slot to become available. The resolution is to simply start executing some scripts by adding them to the page, thereby freeing up more preloading slots.

-- a sub-idea for this suggestion is to have, instead of a hard-cap, a soft-cap, where if it's hit, a user-prompt happens (like the "long-running JavaScript" prompt), where a user can decide if the browser should be allowed to keep going with preloading or be capped.

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Dynamic Script Execution Order

2011-02-21T14:51:13Z

Getify: bolding the update text

This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

'''*Update: The main proposal listed here, also known as "async=false", was recently [http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 officially adopted] [http://ln.hixie.ch/?start=1296711456&count=1 by Ian Hixie] into the HTML Specification.'''
[[User:Getify|Getify]] 00:31, 14 February 2011 (UTC)

A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.

Briefly, this issue has arisen because recent "nightlies" changes in both Mozilla Gecko and Webkit have broken the ability for script-loaders like [http://labjs.com LABjs] to be able to download scripts in parallel but ensure their execution order. As a result of the discussion, it's become apparent that both the spec for, and various current browser implementations around, dynamic script loading is incomplete in addressing this use case, and that some change needs to occur.

There is one main proposal that has surfaced from the discussions, with several other alternatives having been discussed. This page will try to distill the long email thread down and clearly present the main proposal, objections, and alternative suggestions.

Please feel free to join the discussion of this topic in the [[Talk:Dynamic_Script_Execution_Order]] area.

== Use Case Description ==
Script tags/elements can either:

a) appear in the HTML markup ("parser-inserted"), OR

b) be dynamically appended to the DOM using document.createElement() ("script-inserted")

Parser-inserted script tags, up until recent browser versions, had the undesirable performance behavior of loading and executing serially, blocking everything else while doing so. Recently, many browsers have improved the situation by loading the scripts in parallel, but still executing them in order.

On-demand (or dynamic) script loading has emerged in recent years for a variety of different reasons, most notably the performance improvements to address such concerns. It is desired by many different scenarios to be able to download scripts to a page completely independently of the loading of the rest of a page's resources, or even well after a page has finished loading ("on-demand").

Recent additions to HTML spec such as "defer" and "async" were intended to address the use-case for parser-inserted script elements, but their behaviors have been unhelpful for the on-demand loading use-case (script-inserted script elements).

Thus, script loaders (like [http://labjs.com LABjs]) were developed to give page authors an easy way to specify one or more scripts to load (regardless of when in the life-time of the page that loading is requested), and for as many of them as possible to load in parallel, and for those scripts to be loadable from any local or remote domain location, and for the script loader to be able to control the execution order (if the usage of the script loader's API expresses the need to) to preserve dependencies between the scripts.

Sometimes, dynamic script loading is used to load totally independent scripts, and thus "as fast as possible" execution is desired. Other times (and possibly more frequently), multiple scripts are loaded with some dependencies among them, requiring them to execute in a certain order.

What is needed is some facility by which a script loader can express that dynamic script loading either does or does not need execution order preserved among the queue of requested script loadings.

=== Current Limitations ===
Unfortunately, browser behavior around script-inserted script elements and their loading and execution behavior is splintered. There are, at present, two main camps of behavior:

a) in IE and Webkit (including Chrome), the default behavior for script-inserted script elements is for them all to execute in "as fast as possible" mode, meaning there's no guarantee about ordering. This effectively makes on-demand (dynamic) script loading impossible to work in parallel-mode if the resources in question have dependencies -- the only straight-forward way to handle things is to load each file and execute, serially, losing the parallel loading performance benefits.
<blockquote style="background-color: #EEEEEE">
I'm not sure if this is the case.

IE will start fetching resources without execution simply by setting the src attribute. Scripts will not execute, however, until they are added to the document. Since IE supports the readyState attribute and readystatechange event, it's possible to load scripts in parallel and execute them in order without resorting to invalid type attribute hack-ery.

<pre style="background-color:white" lang="javascript">
script= document.createElement("SCRIPT");
script.onreadystatechange= function(){
if(this.readyState == 'loaded')
/*
Network fetch is now complete, following
triggers synchronous execution.
*/
document.body.appendChild(this);
else if(this.readyState == "complete")
this.onreadystatechange= null;
}
script.src= "foo.js";
/* Network fetching begins now */
</pre>
</blockquote>

<blockquote style="background-color: #ccc">
I've experimented with such things heavily in the past, and I'm fairly suspicious that this is not reliable across various versions of IE (6-9), nor does it work reliably the same depending on if an element is already in the browser cache or not. I'm not 100% certain that what you suggest is flawed, but I have a strong hunch that it can be shown to have some holes in it for IE loading. I will try to create some test cases to prove or disprove.
<blockquote style="background-color: #EEEEEE">
When loading a script that is in the cache, IE requires the event handler be installed prior to setting the `src` attribute. Otherwise the element's transition to the "loaded" state will be missed. IE routinely "skips" ready state transitions when cached scripts are immediately inserted into the DOM so suspicion is understandable; however, delayed insertion works around this "problem". The script above has been tested in IE6-8 with scripts in a variety of caching states and found to work correctly.
</blockquote>

Moreover, you're suggesting something that is AFAIK only IE right now, <del>and definitely appears to not be standardized. In the same way that I'm hesitant to continue pinning loading behavior on hacks like the invalid type attribute value, I wouldn't want to approach loading with this technique (even if it were proven reliable on all IE's under all caching circumstances) unless it was a serious proposal to the W3C to have this technique be the new standard (as opposed to the current proposal, as implemented by Mozilla and Webkit now).</del>

Update: the behavior *is* in fact in the spec as a suggestion (aka, with "may" instead of "should"). The wording in question is located in [http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML5 4.3.1, "Running A Script" algorithm] step, 12, which states:

<blockquote style="background-color:#f1dac9">
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

[[User:Getify|Getify]] 19:32, 23 December 2010 (UTC)

<blockquote style="background-color: #EEEEEE">
I think you're right: Only IE impelements this event and property on script elements. The readystatechange event, however, is widely understood due to the XmlHttpRequest implementation and `readyState` property has been added to the `document` in WebKit, Mozilla and IE.
</blockquote>

That having been said, I think this is at least a viable candidate for "Alternate Proposals" and deserves to be [[Dynamic_Script_Execution_Order#readyState_.22preloading.22|listed as such]]. As always, I welcome input from the community on all the ideas presented here, including this one. But, since the main proposal (async=false) is already being implemented by at least two major browsers, I'm not sure if the tide will be changed or not.

</blockquote>

<blockquote style="background-color:#ddd;">
Also, the suggestion of handling the "preload" and deferred execution via the script tag's `readyState` property is very similar in spirit to the suggestion that was made to explicitly support [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|preloading into cache without execution]]. As I said, either of those two approaches might work, but they both put more of the onus of complexity in managing multiple dependencies on the high-level code (author, script loader, etc). I'm more in favor of this functionality being explicitly built-in natively into the queues. As always, I welcome comments to any side of this discussion.

[[User:Getify|Getify]] 18:35, 15 December 2010 (UTC)
</blockquote>

b) in Gecko and Opera, the default behavior for script-inserted script elements is for them all to load in parallel, but execute serially in insertion order. Technically, this makes it impossible to dynamically load independent script elements and have them execute in "as fast as possible" mode.

As described above, both behaviors are desirable under different circumstances, but each of the two camps provides only one behavior, and no way to straightforwardly achieve the other. This obviously creates a big nightmare interoperability-wise when trying to provide a general script loader cross-browser.

Since it is observed that the behavior in (a) is more detrimental (race-condition wise) for the case where dependencies exist, script loaders like LABjs had to find some way around this problem while still attempting the best possible parallel loading performance. However, the trick used is hacky and not completely reliable -- yet it is the best way to solve the use-case in <s>IE and </s>Webkit.

For Gecko/Opera, the concession was just (silently) made that the lesser-common use case of "as fast as possible" wasn't possible, but degraded fine to "insertion order execution", while keeping the parallel loading benefits.

<blockquote style="background-color: #EEEEEE">
Gecko's strict execution order creates dependencies between scripts which are unrelated and prevents the ability mitigate the impact of server outages / network latency. This is exacerbated by the fact that Gecko, unlike IE and WebKit, provides no mechanism to <b>remove</b> scripts from the execution queue.

Consider the case where JSONP is used to provide auto-completion. The user types "hello" and the JSONP request is made; however, the "currently" loading script is out-of-date as soon as the user modifies his search to "hello world". Gecko's algorithm requires the out-of-date request load and execute before the second request.
</blockquote>

Recently, Gecko landed a [http://hg.mozilla.org/mozilla-central/rev/a60414d076b5 patch] to the trunk that stopped Gecko's existing behavior of preserving execution order, making script-inserted script elements now execute in "as fast as possible" mode similiar to IE/Webkit. Unfortunately, the "workaround" used in IE/Webkit (described in the next section) for dealing with parallel loading and execution-order dependencies does not work in Gecko, which means presently the use-case in question is now broken in Gecko trunk/FF4 nightlies.

Moreover, Webkit recently landed a [http://trac.webkit.org/changeset/67245 patch] to the trunk that stopped Webkit's non-standard but long-held behavior (also used in the "workaround" described in the next section) of loading into cache script resources with an unrecognized "type" value, but silently not executing them. This behvaior (while hacky) is central to being able to address the use-case in question in Webkit, so at present, Webkit nightlies are now also entirely broken on the use-case (though in a different way than Gecko).

Both the Gecko change and the Webkit change are well-intentioned, as they are bringing the respective browser more in line with the HTML spec. However, what's really been demonstrated is that the HTML spec is not properly handling this use-case, and so the goal is not to address the browser issues raised with more awkward hacks, but to address the shortcomings of the spec first, and then encourage all browsers to adhere to such.

<blockquote style="background-color: #EEEEEE">
Considering Internet Explorer's readyState implementation provides a means of both parallel loading and preserving execution order can be achieved, perhaps its "readyState" property and onreadystatechange event should be included.
</blockquote>

=== Current Usage and Workarounds ===
To work around the limitation in IE/Webkit(prior to the above noted patch) of not being able to rely on script order execution for parallel loaded scripts, a "preloading" trick was developed. This trick relied on non-standard (but long-held) behavior in these browsers that a script-inserted script element with an unrecognized "type" value (such as "script/cache") would be fetched/loaded, but would not execute. This had the effect of loading the resource into cache, and then firing the "load" handlers to let the page know when the resource was completely in cache.

Assuming that the resource was served with proper caching headers, and was in fact in the cache, it could then be executed (nearly) immediately when it was the proper execution order time by re-requesting the same resource via another script-inserted script element with the proper "text/javascript" type value, pulling the resource from the cache and executing it, without another server round-trip.

Of course, the assumption of proper cache headers is a huge one, and not at all reliable. Some recent estimates by performance optimization specialists have suggested as much as 70% of scripts across the internet are not served with proper caching headers, which means that such scripts would be completely ineffective if loaded using this (or a similar) technique. The script resource would end up being loaded completely a second-time, and the "near immediate" execution would obviously be false, and thus race conditions would ensue.

It's important to note at this point that the new <link rel=prefetch> facility has been suggested as a better workaround, but it suffers the same ill-fated assumption of script cacheability. Still others have suggested "new Image().src=..." or the [http://www.phpied.com/preload-then-execute/ <object> preloading trick] suggested by Stoyan Stefanov. Again, these tricks unwisely assume cacheability, for the "preloading" trick to solve the use-case in question.

=== At Risk ===
Currently, there are several large/popular web sites which are either currently (or who intend to soon) use LABjs in such a way as to run afoul of the new Gecko and Webkit behavioral changes with LABjs failing to operate properly. It's important to note that the problems of race conditions can be subtle and hard to detect, and so merely loading up such sites and failing to observe overt failure is not sufficient.

Sites which are known to have LABjs loading techniques in place with currently broken (or susceptible to such breakage in the near future) behavior are:

* [http://twitter.com Twitter]
* [http://zappos.com Zappos]
* [http://vimeo.com Vimeo]
* [http://mefeedia.com MeFeedia]
* [http://blog.getify.com Getify Solutions blog (my blog)]
* [http://flensed.com flensed Flash+JavaScript browser shims (cross-domain Ajax, cross-browser cookies, etc)]

Rather than getting hung up in the syntax of usage in LABjs that is or is not going to break, it's best to just think of the problem this way:

Does a site need to load more than one script, at least one of which comes from a remote domain location (like a CDN), and for which among the scripts there's at least one execution-order dependency among them? If so, then that site is susceptible to the current/future breakage if the HTML spec (and browsers) do not address this use case.

A common example (in use on many sites) of such might be loading:

* jQuery from the CDN
* jQuery-UI from the CDN
* plugins and usage code in one or more local files
* Google Analytics from the Google domain

Note that the emergence of popular script frameworks and their hosting on public CDN's is leading to more and more sites loading scripts from both local and remote locations, and also to loading more files that have dependencies (rather than the practice of concat'ing all files into one file to avoid dependency issues).

Any site which fits a profile like the above, and which might currently (many do), or in the future want to, use a script loader to improve their loading performance, will fail to achieve what they want cross-browser and in a performant way, if the HTML spec (and browsers) do not address the use case.

=== Benefits ===
The benefits of addressing both behaviors directly (without "preloading" tricks and bad assumption reliance) have been implied in the above discussion, but in short are:

a) clear and simplified code for script loaders, which leads to easier use by authors of more pages, which in turn leads to better web performance (as demonstrated clearly by intelligent script loading techniques as compared to just simple <script> tags in HTML markup)

b) full access to either/both of the execution-order behaviors (as the author sees fit), regardless of browser

c) avoiding reliance on bad assumptions (like cacheability) as a sufficient way to address the use-case

=== External Discussions of this Feature ===

* <cite>[http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html W3C public-html email thread]</cite>

* <cite>[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 W3C Bug #11295]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=620852 Mozilla Bug #620852]</cite>

* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>

* <cite>[http://hsivonen.iki.fi/script-execution/ HTML5 Script Execution Changes in Firefox 4 Beta 7]</cite>

* <cite>[http://blog.getify.com/2010/10/labjs-w3c-brief-update/ LABjs and W3C... brief update]</cite>

* <cite>[http://blog.getify.com/2010/10/ff4-script-loaders-and-order-preservation/ FF4, script loaders, and order preservation]</cite>

== Proposed Solutions ==

=== My Solution ===
The current proposal most well supported from the email discussion thread, and the one which I feel makes most sense, is described here.

The HTML spec already defines the "async" attribute for parser-inserted script tags, which when set to "true", changes their execution order behavior to be like script-inserted script-elements (in IE/Webkit), which is that they load in parallel and execute "as fast as possible" (ostensibly because the author is expressing no dependencies between multiple such "async"-marked scripts). Parser-inserted script elements without "async" (or with it set to false) behave as before and expected, which is that they load in parallel but execute in order.

However, the HTML spec does not define the "async" property (or any such behavior) for script-inserted script nodes (such as those created by a script loader). Instead, the spec implies that "async=true" like behavior is always true for such script-inserted script elements.

What is proposed is:

a) Script-inserted script elements should have (and respect the value of) an "async" property which is basically identical to the "async" attribute for parser-inserted script elements. That is, script elements with the "async" property set to "true" will behave accordingly, as will script elements with the "async" property set to false.

Essentially, the proposal is to mirror the "async" attribute behavior of parser-inserted script elements as an "async" property on script-inserted script elements. This has the benefit of using an existing facility and extending it (from current spec) in a way that is sensisble and symmetric with its current definition.
<blockquote style="background-color: #EFEFEF">
The scriptgroup or `readyState` alternate proposals allow for dependency management to be done in high-level code. The singular syncrhonized execution queue proposed here introduces artificial dependencies, undermining some of the benefits dynamic script loading provides.
</blockquote>

<blockquote style="background-color: #ccc;">
It's important to note that `async=false` scripts will load in a separate queue from `async=true` scripts. It's not that all scripts will now be forced into this insertion-order-execution queue. An author (or script loader) can chose which queue to put a script loading into based on the needs of the page and the resource. If I have a few scripts that are unrelated to each other and the main page (like Google Analytics, social sharing buttons, etc), I'll load those via `async=true`. For other scripts, where order matters for dependency sake, I'll use `async=false`. I think having both those queues available to high-level code is enough control over loading to serve the majority of use-cases pretty well.
<blockquote style="background-color: #EFEFEF">
If at any point these services begin dynamically loading `async=false` scripts of their own, they will begin blocking. This can lead to unexpected behavior of existing code as third-party libraries and services change. It would seem the specification should provide a means by which this blocking can be isolated to dependencies defined by the author and ordered execution not introduce conditions that allow unrelated libraries to affect this.
</blockquote>
</blockquote>

b) Furthermore, to aid in "feature-detection" of such new behavior, the proposal is to have the default value for the "async" property of script-inserted script elements be "true" (and of course the associated behavior thereof).

There are two major benefits to (b). One is that it provides a way to feature test such new behavior by not just looking for the existence of the "async" property on script elements, but specifically that the default value is "true" (which is opposite of what it would currently/normally be). Secondly, defaulting to "async=true" behavior for script-inserted script elements would preserve the default behavior of IE and Webkit, meaning there'd be less of a chance of breaking existing web content in either of those two browsers.

It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.

==== Proposal Amendment: Need Attribute/Property Semantic Inconsistency ====
In order to achieve consistency between the semantics of how the parser-inserted script element's `async` attribute and the script-inserted script element's `async` property behave, a slight change needs to be made to the value parsing/interpretation for parser-inserted script elements' `async` attribute.

If a parser-inserted script element has the `async` attribute present, but its value is exactly "false" (or any capitalization thereof), the script element should behave EXACTLY as if no `async` attribute were present.

If the attribute is present and either has no value, or has any other value except "false" (for instance, "true" or "async"), then it should be interpreted to be turning on "async" for that element.

Because it is highly unlikely (and indeed, quite irrational) that any existing web content is doing `async="false"` in HTML markup and yet still expecting "async" behavior to be turned on, it is pretty unlikely that this minor interpretation change will cause backwards-compatibility issues.
[[User:Getify|Getify]] 03:05, 22 December 2010 (UTC)

==== Proposal Amendment: Events ====
In addition to standardizing how scripts load and execute, it's also important to standardize the load and error events, and under what circumstances they fire, etc. Without reliable load/error events, the main proposal is not reliable and is thus unhelpful for the use-case.

A script-inserted script element must fire the "load" event only once, when:

a) immediately after the resource finishes loading, but before parsing/execution, AND

b) the script element loads any non-empty content (that is, it was a successful HTTP request), AND

c) the script element has either loaded from the remote location, or is loaded from the brower cache

Specifically, the script "load" event must come immediately between the script element finishing loading and the script element being parsed/executed. If the script resource successfully loads, nothing should interrupt the sequence of fininshing loading, the "load" event firing, and the script being parsed/executed.

A script-inserted script element must fire the "error" event only once, when:

a) immediately after a loading failure for the resource is detected (that is, an HTTP error received, such as 404, 500, 503, etc).

Either the "load" or "error" event, but not both, will fire, and only once, for every script-inserted script element.

NOTE: "load" and "error" events on script-inserted script elements must fire synchronously to ensure event reliability.

A case may be made for adding the "load" and "error" events as described here to parser-inserted script elements as well.

==== Processing Model ====
Script inserted script elements will have an "async" property that defaults to "true". If the author does not change the value, all such requested script loadings will be in their own "queue" and will default to "as fast as possible" execution behavior. For any script elements that the author sets "async=false", those scripts will load in a separate "queue", and will execute in insertion order only. Again, these two "queues" will operate strictly independent of each other.

==== Processing Model Details (without the event amendment) ====

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node.

When a previously-created script element node loses its parser-insertedness, if the element doesn't have the async content attribute, set the force-async flag to true and false otherwise.

When a script element node obtains the async content attribute (via setAttribute, setAttributeNode, setAttributeNS, by the fragment parser or the XSLTProcessor adding the attribute, etc.), set the force-async flag to false. (Note that calling removeAttribute("async") doesn't modify the force-async flag.)

The async IDL attribute must behave as follows:
* Upon setting, set the force-async flag to false and then reflect the async content attribute.
* Upon getting, if the force-async flag is true, return true. Otherwise, reflect the async content attribute.

In step 13. of http://www.whatwg.org/specs/web-apps/current-work/#running-a-script before the case "If the element has a src attribute" add a case:
If the script has a src attribute and the async IDL property getter returns false,
The element must be added to the queue of ordered script-inserted external scripts of the Document of the script element at the time the running a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run these steps:
# If the queue of ordered script-inserted external scripts is empty or the first script in the queue of ordered script-inserted external scripts has not been fetched yet, abort these steps.
# Execute the first script in the queue of ordered script-inserted external scripts.
# Remove the first script from queue of ordered script-inserted external scripts.
# Goto step #1.

Modify step 5 of http://www.whatwg.org/specs/web-apps/current-work/#the-end to say:
Spin the event loop until the set of scripts that will execute as soon as possible is empty and the queue of ordered script-inserted external scripts is empty.

==== Limitations ====
The two behaviors being identified solve either the case where no dependencies exist, or where a linear dependency chain exists (and which the script elements can be requested to execute in that order). It is possible that some authors have a more complex non-linear dependency chain that they would like to express. This would obviously require a much more complex API and spec change, and since that use-case has not (yet) surfaced as a particularly main-stream request, I believe it would be overengineering to try to address it with this proposed change set.

In addition, it's been duly noted that it's undesirable (and potentially confusing/problematic) to intentionally build in the inconsistency of having the "async" attribute (for parser-inserted scripts) and the "async" property (for script-inserted scripts) have different default values ("false" for the attribute, "true" for the property).

It's also been a point of discussion whether or not such a spec change has enough "carrot" to entice the browser vendors (namely IE and Webkit) to implement the behavior. Moreover, there's been some concern that if the default value for the "async" property were made to be "false" (like the attribute) to be more consistent and conservative, then it would possibly give the perception to IE and Webkit of "losing" some performance to cut out their default "as fast as possible" behavior.

=== Alternate Proposals ===
One early proposal on the email list was to introduce an entirely new property like "ordered" which an author could add to a script-inserted script element to instruct the browser to put it into the queue of execution-order-preserving script loadings. While such a property would address the use case, it introduces another property and thus more complicates the issue. It also fails to address the current spec inconsistency (which is confusing to new comers) that "async" is not a present/respected property in mirror of the attribute of the same name.

Another suggestion was a "waitFor" property that would be added to script elements and would specify a list of one or more DOM id's of other script elements that the current script should "wait for" in terms of execution. Again, this would solve the use case, but in a more complicated way, and there are concerns that it would be too confusing for the normal use-case.

Several suggestions have come in the form of creating explicit "preloading" (similar to <link rel=prefetch>), but as described above, "preloading" to solve this use case is a non-ideal hack and highly susceptible to breakage if the script fails to be sent with proper caching headers.

It's also been suggested that since this type of behavior is somewhat complicated, it may be better to intentionally obfuscate or complicate any such facility in the HTML, so as to make the barrier-to-entry rather high and force users to know what they are doing before doing it.

It's been suggested that "defer" already preserves execution order. However, "defer" is only defined for parser-inserted scripts, and thus is not applicable to the use-case in question from an on-demand point of view. Also, "defer" scripts explicitly way for DOMContentLoaded, even if they're ready to execute sooner. So this is less than desired.

Yet another proposal is a "document.executeScripts()" API, where an author can specify multiple sets of scripts that can load in parallel and it will enforce their execution order. A variation on that same idea was to use the "importScripts" from the Web Workers spec, however "importScripts" is synchronous (undesirable performance wise, obviously). The main downside (besides extra API complication) to "document.executeScripts()" is that there seem to be quite a few script execution properties/behaviors (including "document.currentScript" and charset override) which would have to be duplicated into this API facility.

==== "Script Group" element ====
One recent alternate proposal bears some special consideration, as it seems like it might be a decent option (although certainly more of a radical change for the spec and for browsers to implement). But it has the appearance of being pretty straightforward and semantic for authors to use, perhaps even more so than using "async".

The proposal is to create a new HTML element, called perhaps <scriptGroup>, <collection>, etc. Specifically, this element must be able to be inserted wherever a <script> element can currently be inserted. The "script group" element is intended to signify that all script elements added to it must perserve insertion execution order. This element wouldn't have much (but still some, explained in a moment) meaning in a parser-inserted context, since parser-inserted scripts already preserve order among themselves.

An advantage of the "script group" element would be to give a direct and easy way to attach event listeners ("load" and "error") to the entire group, rather than having to internally track events for each element if all you care about is the final "load" event, for instance. In the case of event handling, the "script group" element would have perhaps some benefit even in parser-inserted (markup) context.

The element would need to have an "id" property, and possibly attributes for "load" and "error" events.

A variation on how to look at this proposal is that a "script group" element could have an attribute/property on it (perhaps called "ordered") which would allow the group to either be order preserved or not. This would make the "script group" element much more useful in the parser-inserted context, as it would sort of be a shortcut to setting "async=true" on all the child script elements.

The "script group" element might look like this:

<scriptGroup id="group1">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

Or, with the "ordered" attribute to explicitly control ordering behavior for the group:

<scriptGroup id="group1" ordered="true">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

<scriptGroup id="group2" ordered="false" onload="alldone();">
<script src="baz.js"></script>
<script src="far.js"></script>
<script src="zab.js"></script>
</scriptGroup>

While the "script group" element is definitely more complicated to define and implement, it does have some semantic advantages for authors, and it also would significantly reduce the internal complexity of script loaders like LABjs. It would give authors (either directly or through script loaders) the flexibility to group scripts together into one of the two aforementioned behaviors (execution "as fast as possible" or "in insertion order"), and to easily access both behaviors in the same page.

==== Explicit support for "text/cache" MIME type behavior ====
Yet another alternate proposal has been suggested in the [[Talk:Dynamic_Script_Execution_Order]] thread.

Essentially, the proposal is that <script> tags directly support being declared with a `type` value of "text/cache". The behavior would be that the script resource is fetched, as the load events fired, as normal, but that the script itself would not be executed. Then later, at the desired time, the script in that element could be executed by changing the `type` value from "text/cache" to "text/javascript".

The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.
<blockquote style="background-color:#eee">
And does the onload event fire again after the script executes? <br/>
Or only when it's loaded? <br/>
Both seem to violate current `onload` semantics.
[[User:Serverherder|Serverherder]] 20:27, 15 December 2010 (UTC)

<blockquote style="background-color:#ccc">
As far as I'm concerned, I think the "load" event should happen immediately after a script loads, but before it executes, as I spell out in the [[Dynamic_Script_Execution_Order#Proposal_Amendment:_Events|Events proposal ammendment section]]. [[User:Getify|Getify]] 20:33, 15 December 2010 (UTC)
</blockquote>

</blockquote>

==== readyState "preloading" ====
Per the suggestion/comment added to the above [[Dynamic_Script_Execution_Order#Current_Limitations|Current Limitations]] section, it's been suggested that IE's current behavior with respect to the `readyState` property can adequately serve the use-case in question. This alternate proposal is very similar in spirit to the [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|previous section on explicit support for "text/cache"]] mime-type value.

The idea is that IE will begin fetching into the cache a script resource as soon as the `src` attribute of the dynamic script element is set. But IE will not execute the script (even if it finishes loading) until the script element is added to the DOM. However, the `readyState` property of the element, combined with the `onreadystatechange` handler listening for changes, can detect when the script has finished loading, by receiving the "loaded" value.

In this way, a script loader could "preload" a set of scripts all in parallel, but control their execution order by delaying the appending of the element to the DOM until execution is desired.

'''Update''' [[User:Getify|Getify]] 14:10, 20 December 2010 (UTC)

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

This seems to be the spec stating that browsers may do what IE's behavior on scripts does, which is to start fetching the resource once the `src` property is set, but not execute it until the script element is inserted into the DOM.

It would seem then that browsers could/should be petitioned to consider implementing this suggestion, perhaps taking the `readyState` implementation from IE as guidance. While I'm still not sure that this would be my preferred method of solving the overall use-case in discussion on this page, it would be an option for such, and it would also help other use-cases, such as those being discussed in this W3C public-html thread:

[http://lists.w3.org/Archives/Public/public-html/2010Dec/0174.html Need to: "preload" CSS and JS]

==== Do nothing and encourage vendors implement the existing suggestion ====
As noted by Getify above, the spec all ready makes the suggestion that a script's SRC attribute be fetched immediately upon assignment.

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

While not explicit, it seems the specification all ready deals with the use-case this is hoping to achieve: It makes parallel loading scripts '''optional'''. Execution order can all ready be handled by loaders using onload-chaining. Therefore, parallel loading can be achieved, but only in browsers that have chosen to implement the suggestion.

Given this, the discussion can shift to:
# Should the suggestion be changed to a mandate?
# Should the specification include a way to '''force''' parallel loading?
# Should we be petitioning vendors, not the the W3C, to implement the existing suggestion?

[[Category:Proposals]]

Script Execution Control

2011-02-14T15:31:59Z

Getify: adding simple formatting

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

'''The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).'''

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

<del>2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.</del>

[[User:Getify|Getify]] 15:24, 14 February 2011 (UTC)

2. This proposal requires changes from IE to achieve full-compat. As IE is known to have a much slower release timeline, and IE9 is now feature-complete and nearing a full release soon, the likelihood is that this current IE cycle has been missed for any such changes. That means full-compat would probably be at best 1-2 years from now.

[[User:Getify|Getify]] 15:27, 14 February 2011 (UTC)

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

'''The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.'''

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Script Execution Control

2011-02-14T15:27:13Z

Getify: adding note about IE compat

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

<del>2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.</del>

[[User:Getify|Getify]] 15:24, 14 February 2011 (UTC)

2. This proposal requires changes from IE to achieve full-compat. As IE is known to have a much slower release timeline, and IE9 is now feature-complete and nearing a full release soon, the likelihood is that this current IE cycle has been missed for any such changes. That means full-compat would probably be at best 1-2 years from now.

[[User:Getify|Getify]] 15:27, 14 February 2011 (UTC)

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Script Execution Control

2011-02-14T15:24:34Z

Getify: updating to reflect the current state of the proposal

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

2. <del>In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.</del>

[[User:Getify|Getify]] 15:24, 14 February 2011 (UTC)

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Script Execution Control

2011-02-14T04:47:41Z

Getify: link title correction

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Script Execution Control

2011-02-14T04:39:09Z

Getify: updating links with new page title

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Script Execution Order Control

2011-02-14T04:37:47Z

Getify: moved Script Execution Order Control to Script Execution Control: The word "Order" in the title was slightly misleading to the main intent of this page and proposal

#REDIRECT [[Script Execution Control]]

Script Execution Control

2011-02-14T04:37:47Z

Getify: moved Script Execution Order Control to Script Execution Control: The word "Order" in the title was slightly misleading to the main intent of this page and proposal

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Order_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Order_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Order_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Order_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Script Execution Control

2011-02-14T04:32:10Z

Getify: adding a few of the insufficient solutions

This page is intended to formalize the discussion around the ability to control (aka, defer until desired) the execution of a script, to occur sometime after the script finishes loading.

This feature, with two main proposals for how to accomplish it, has been discussed on in a long email thread on the WHATWG list: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution"]

[http://nczonline.net Nicholas Zakas] began the WHATWG thread with his proposal, which he has since refined and is now in version 2.1 at: [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2].

This page is being created to document that first proposal, as well as a second proposal (which actually came as a result of feedback on another WHATWG wiki page/proposal: [[Dynamic_Script_Execution_Order]]) for the same functionality. These are the two main solutions being discussed at the moment. This page will also attempt to distill some of the feedback and other (unfortunately unsuitable) proposals discussed thus far.

Please feel free to join the discussion of this topic in the [[Talk:Script_Execution_Order_Control]] area.

== Use Case Description ==
The use-case is that one or more scripts may be necessary to download, but not to automatically execute. The reasons for wanting to defer the execution of a script element until on-demand later are varied. They include performance issues with limited CPU's on mobile devices, the ability to choose based on user-action which of two scripts should be applied, the ability to delay the execution of a script until the user-action activates some part of a page, etc.

In addition, this functionality as described will be useful for parallel script loaders, giving them the ability to download multiple scripts in parallel, but control their execution order by deferring the execution of all of them, and then once they are all loaded, executing them on-demand in desired order. The base-version of this application of the use-case was addressed by the "async=false" behavior, recently adopted by the Specification, but would be bolstered and improved by the functionality in these current proposals.

=== Current Limitations ===
There's no way to defer the execution of a script element, except by use of the `defer` attribute in markup script elements (meaning it's inaccessible to dynamic script loaders). However, the `defer` attribute in markup still only allows deferring until after DOMContentLoaded (aka, "DOM-ready"). Several applications of the use-case call for an abitrary, author-controlled point to decide when scripts should execute, not locked to DOM-ready.

With regards to the "async=false" behavior being improved with this proposal, script loaders cannot currently (with "async=false") specify multiple "groups" of scripts which have order-dependency within the group, but the groups themselves are completely independent. There's no way to currently download all scripts in groups 1 and 2, but allow either group 1 or group 2 to execute when the first one finishes. Currently, the only way to do this based on specification is to use "async=false", and then all the scripts will execute in the order added to the DOM -- the "independent grouping" of execution is not possible.

=== Current Usage and Workarounds ===
Currently, this functionality is available in IE (since version 4). To achieve this functionality in other browsers, there's two main types of hacks to accomplish it:

1. The content may be "wrapped", for instance in /* ... */ comments, such that its automatic execution will be moot. Then, the page can, at the desired time, grab the script content, remove the comment markers, and re-execute the code. This technique only works for inline script elements, not for externally loaded script elements (which also means that any caching benefit is lost).

2. The page can employ one of a variety of "cache preload" tricks (different for each browser), whereby the script is loaded into the cache but not executed, and then when execution is desired, the script is re-requested with a proper script element, and thus executed. The main drawback to this approach is the assumption of cacheability. If a script was not properly cached, this technique will result in a costly double-load. Also, as stated, these hacks are brittle and require different variations for each browser. They are quite susceptible to future restrictions by the Specification, or by changes to browsers' optimization techniques.

=== Benefits ===
The primary benefit underlying all the use-cases of this proposal is performance. It gives the page more control over execution of downloaded scripts, allowing the page author to make tradeoffs on when scripts are executed in an attempt to optimize for the user-conditions and experience.

The secondary benefit is to reduce (greatly) the complexity (and hackiness) of script loaders (like LABjs, ControlJS, etc) which go to great lengths to employ tricks and hacks to accomplish this described functionality in existing browsers.

=== External Discussions of this Feature ===
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030161.html "Proposal for separating script downloads and execution" (WHATWG email list thread)]</cite>

* <cite>[https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1]</cite>

* <cite>[[Dynamic_Script_Execution_Order]]</cite>

* <cite>[http://www.stevesouders.com/blog/2010/12/15/controljs-part-2/ Steve Souders' ControlJS]</cite>

== Proposed Solutions ==

=== Proposal 1 (Nicholas Zakas) ===
This proposal is described in detail in Nicholas Zakas' [https://docs0.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO Delayed Script Execution v2.1], but will be summarized here for clarity of this page.

This proposal recognizes the need for an event mechanism to detect when a script is preloaded, as well as the need for a feature-detect to detect if the functionality is implemented in a browser.

The proposal is:

1. Add a `preload` property to dynamic script-created script elements (*not* markup script elements), which defaults to false, that can be set to `true` *before* the setting of the `src` property. Turning on "preload" will cause the script to be loaded immediately, even if the script has not yet been added to the DOM.

2. Add a `onpreload` event, which fires when the script element finishes preloading. The script element can then, at that event time, or later, be executed by adding the script element to the DOM through normal procedures.

3. The feature-detect will be:

(typeof document.createElement(“script”).preload == “boolean”)

The goal of this proposal is to be as semantic as possible to what is actually occurring (thus the use of the very descriptive and appropriately named `preload` and `onpreload`).

==== Limitations ====
1. This proposal's main limitation is that it requires a new property and a new event (which is not precedented anywhere else in the HTML specification yet). That means that the proposal will require more effort on the part of the Specification as well as on the part of browsers to implement.

2. In fact, for full adherence to this proposal, it will actually require a change to IE's existing behavior, to make it not "preload" if the `preload` attribute is not set. This is quite possible to create backwards-compat concerns from the IE team.

=== Proposal 2 (Kyle Simpson) ===
This proposal is, in spirit, very similar to [[Script_Execution_Order_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

Put simply, this wording says that a script may begin downloading as soon as the `src` property is set on a dynamic script element, even if that element is not added to the DOM. Further, it suggests that adding the element to the DOM is necessary to execute the script. From this, we can infer that a script may be "preloaded" by creating and keeping references to script elements, but not adding them to the DOM. And then when the script is desired to execute, the script element can be added to the DOM.

In addition to this wording already being in the specification, the functionality as described has been implemented in IE since version 4.

As with [[Script_Execution_Order_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]], this proposal also requires an event mechanism which can allow the web author to be notified of when a script element is finished preloading. In addition, both proposals require a "feature-detect" so that web authors can opt-in to the described behavior after detecting that it is present in a browser.

The proposal is:

1. Change the above referenced wording (as necessary) to indicate that the preloading behavior is required rather than being a performance suggestion.

2. Taking IE's implementation as the pattern, specify the `readyState` property on the script element (defaults to "uninitializd"), and fire `onreadystatechange` events when the script is "loaded" (finished preloading) and "complete" (finished executing, ~ similar to `onload`). The `readyState` functionality is already precedented in the specification for the XHR object, so that same pattern and wording could/should be applied here.

3. The feature-detect will be:

(document.createElement("script").readyState == "uninitialized")

The reason for checking not only the `readyState` variable but also its value is that Opera currently implements a non-functional `readyState` property on the script element (but does NOT support the proposed functionality), but Opera's default value is "complete". The feature-test would give a false-positive in Opera if the value isn't included in the test. Opera has stated in the WHATWG discussion thread that they would not not change the default value of `readyState` to "uninitialized" unless they were also implementing the behavior described in this proposal. No other known browsers have `readyState` on script elements, and the assumption is that any new browser implementations adopting it would adhere to the specification (if this proposal is adopted). So, the proposed feature-detect should be reliable.

This proposal allows scripts to be added to the DOM before they are finished loading, as they currently can, with no change in current behavior. It also does not specify any different model for script execution than is currently present in browsers. In other words, under the circumstances that a browser would execute a script synchronously, the same would be true, and under the circumstances a script would be queued for execution asynchronously as soon as possible, the same would also be true.

The goal of this proposal is to make the minimum change to both specification and browser behavior necessary to fulfill all the goals of the stated use-case. It does not introduce any new, unprecedented elements or concepts, and instead builds on existing specification wording and actual browser implementation.

==== Limitations ====
1. The feature-detect is riskier/weaker/more brittle, and not as graceful as in [[Script_Execution_Order_Control#Proposal_1_.28Nicholas_Zakas.29|Proposal 1]]

* Yes, it's less graceful of a feature-detect. But as explained, it *is* functional. Given appropriate evangelism and involvement with browser vendors, if this proposal were implemented as described, the feature-detect should not be risky.

2. The proposal does not address the use-case of deferring inline script elements' execution

* Yes, neither of the proposals are seeking to fill this use-case, but this proposal is not really capable of it, whereas the other proposal *could* be extended to include markup script element support for that use-case. There's not yet been sufficient evidence of that use-case being necessary.

== Insufficient Solution Suggestions ==

=== <link rel=prefetch> ===
One suggestion in the thread, which has come up numerous times, is that the already spec'd <link rel=prefetch> mechanism could address the use-case.

There are a few problems with this idea.

1. <link rel=prefetch> is currently only defined for <link> tags in markup. The main use-case is specifically about script loaders needing functionality from dynamica script-created script elements.

2. `prefetch` is defined specifically as a "hint" to the browser that it might benefit from loading a resource ahead of time. The description makes it clear the intended use is for preloading resources which may be used on another page. That's a poor fit for this use-case, because the script loader needs a specific way to say to the browser "I need this resource to load now, because I'm definitely going to use it later".

3. Once an element would be loaded via <link rel=prefetch>, the question arises as to how that resource can later be executed. There were two main options:

* Add an `execute()` method to the <link> element, that can be used to execute a script that was preloaded. This is problematic because of all the complicated functionality around script elements and their content's execution, and would require basically copying all those rules over to the <link> element, or at the very least morphing the <link> element into a <script> element at time of execution. This is most likely more trouble than it's worth.

* Simply re-request the resource at desired time of execution with a proper <script> element container. The problem here is that then the solution becomes just as fatally assumptive as the "cache preloading" tricks referred to earlier in this page. If the resource didn't/couldn't properly cache, the second request would result in a costly double-load. There's simply no way to guarantee that a resource can cache so that a second request can use it directly.

4. The link element does not currently have a well-defined event system that could inform a web author of when the "prefetch" had finished. As is clear from both the main proposals, an event mechanism is crucial for fulfilling the more advanced applications of the main use-case, and the whole system is not worth proposing without such an event notification.

=== all script content must be adjusted not to auto-execute ===
It has been suggested numerous times in the discussion thread that the simplest solution is for a script author to re-arrange the way a script is written, such that is has no directly executing functionality in its main code section. That way, the script is "safe" to execute (since it does nothing), and its functionality can easily be called upon at later times when actual "execution" is desired.

This argument misses the true nature of the use-case and proposal in two ways:

1. In the mobile-device world, especially, it has been observed that the mere "parsing" (that is, interpreting of a block of code for its function declarations) of a large chunk of code can be so CPU intensive as to overwhelm the device and cause slow-downs in the UI/UX, or even freezes for brief periods of time. The Gmail Mobile team for instance [http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html famously used the /* ... */ comment hack] to hide code from the engine, which drastically reduced their UI latency issues on some mobile devices.

Many other experiments of this nature have been conducted, and the conclusion is that deferring the interpretation-execution of the script is critical to the use-case. So re-writing the script would do no good, unless it were to involve such hacks as the comment hack, which have obvious draw-backs to both the developer and the browser's caching/optimization efforts.

2. The proposal is an attempt to address real-world use-cases on existing sites and using existing standard script libraries (things like jQuery for instance). It is not feasible to suggest that all content which needs execution-deferral must be subject to fundamental API re-writes. If arbitrary JavaScript code in use on today's web cannot be made to download and execute in a more performant way without re-writes, then the whole intent of this proposal (and the greater web optimization community) is a bust.

[[Category:Proposals]]

Dynamic Script Execution Order

2011-02-14T00:31:49Z

Getify: adding note about adoption into the spec

This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

*Update: The main proposal listed here, also known as "async=false", was recently [http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 officially adopted] [http://ln.hixie.ch/?start=1296711456&count=1 by Ian Hixie] into the HTML Specification.
[[User:Getify|Getify]] 00:31, 14 February 2011 (UTC)

A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.

Briefly, this issue has arisen because recent "nightlies" changes in both Mozilla Gecko and Webkit have broken the ability for script-loaders like [http://labjs.com LABjs] to be able to download scripts in parallel but ensure their execution order. As a result of the discussion, it's become apparent that both the spec for, and various current browser implementations around, dynamic script loading is incomplete in addressing this use case, and that some change needs to occur.

There is one main proposal that has surfaced from the discussions, with several other alternatives having been discussed. This page will try to distill the long email thread down and clearly present the main proposal, objections, and alternative suggestions.

Please feel free to join the discussion of this topic in the [[Talk:Dynamic_Script_Execution_Order]] area.

== Use Case Description ==
Script tags/elements can either:

a) appear in the HTML markup ("parser-inserted"), OR

b) be dynamically appended to the DOM using document.createElement() ("script-inserted")

Parser-inserted script tags, up until recent browser versions, had the undesirable performance behavior of loading and executing serially, blocking everything else while doing so. Recently, many browsers have improved the situation by loading the scripts in parallel, but still executing them in order.

On-demand (or dynamic) script loading has emerged in recent years for a variety of different reasons, most notably the performance improvements to address such concerns. It is desired by many different scenarios to be able to download scripts to a page completely independently of the loading of the rest of a page's resources, or even well after a page has finished loading ("on-demand").

Recent additions to HTML spec such as "defer" and "async" were intended to address the use-case for parser-inserted script elements, but their behaviors have been unhelpful for the on-demand loading use-case (script-inserted script elements).

Thus, script loaders (like [http://labjs.com LABjs]) were developed to give page authors an easy way to specify one or more scripts to load (regardless of when in the life-time of the page that loading is requested), and for as many of them as possible to load in parallel, and for those scripts to be loadable from any local or remote domain location, and for the script loader to be able to control the execution order (if the usage of the script loader's API expresses the need to) to preserve dependencies between the scripts.

Sometimes, dynamic script loading is used to load totally independent scripts, and thus "as fast as possible" execution is desired. Other times (and possibly more frequently), multiple scripts are loaded with some dependencies among them, requiring them to execute in a certain order.

What is needed is some facility by which a script loader can express that dynamic script loading either does or does not need execution order preserved among the queue of requested script loadings.

=== Current Limitations ===
Unfortunately, browser behavior around script-inserted script elements and their loading and execution behavior is splintered. There are, at present, two main camps of behavior:

a) in IE and Webkit (including Chrome), the default behavior for script-inserted script elements is for them all to execute in "as fast as possible" mode, meaning there's no guarantee about ordering. This effectively makes on-demand (dynamic) script loading impossible to work in parallel-mode if the resources in question have dependencies -- the only straight-forward way to handle things is to load each file and execute, serially, losing the parallel loading performance benefits.
<blockquote style="background-color: #EEEEEE">
I'm not sure if this is the case.

IE will start fetching resources without execution simply by setting the src attribute. Scripts will not execute, however, until they are added to the document. Since IE supports the readyState attribute and readystatechange event, it's possible to load scripts in parallel and execute them in order without resorting to invalid type attribute hack-ery.

<pre style="background-color:white" lang="javascript">
script= document.createElement("SCRIPT");
script.onreadystatechange= function(){
if(this.readyState == 'loaded')
/*
Network fetch is now complete, following
triggers synchronous execution.
*/
document.body.appendChild(this);
else if(this.readyState == "complete")
this.onreadystatechange= null;
}
script.src= "foo.js";
/* Network fetching begins now */
</pre>
</blockquote>

<blockquote style="background-color: #ccc">
I've experimented with such things heavily in the past, and I'm fairly suspicious that this is not reliable across various versions of IE (6-9), nor does it work reliably the same depending on if an element is already in the browser cache or not. I'm not 100% certain that what you suggest is flawed, but I have a strong hunch that it can be shown to have some holes in it for IE loading. I will try to create some test cases to prove or disprove.
<blockquote style="background-color: #EEEEEE">
When loading a script that is in the cache, IE requires the event handler be installed prior to setting the `src` attribute. Otherwise the element's transition to the "loaded" state will be missed. IE routinely "skips" ready state transitions when cached scripts are immediately inserted into the DOM so suspicion is understandable; however, delayed insertion works around this "problem". The script above has been tested in IE6-8 with scripts in a variety of caching states and found to work correctly.
</blockquote>

Moreover, you're suggesting something that is AFAIK only IE right now, <del>and definitely appears to not be standardized. In the same way that I'm hesitant to continue pinning loading behavior on hacks like the invalid type attribute value, I wouldn't want to approach loading with this technique (even if it were proven reliable on all IE's under all caching circumstances) unless it was a serious proposal to the W3C to have this technique be the new standard (as opposed to the current proposal, as implemented by Mozilla and Webkit now).</del>

Update: the behavior *is* in fact in the spec as a suggestion (aka, with "may" instead of "should"). The wording in question is located in [http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML5 4.3.1, "Running A Script" algorithm] step, 12, which states:

<blockquote style="background-color:#f1dac9">
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

[[User:Getify|Getify]] 19:32, 23 December 2010 (UTC)

<blockquote style="background-color: #EEEEEE">
I think you're right: Only IE impelements this event and property on script elements. The readystatechange event, however, is widely understood due to the XmlHttpRequest implementation and `readyState` property has been added to the `document` in WebKit, Mozilla and IE.
</blockquote>

That having been said, I think this is at least a viable candidate for "Alternate Proposals" and deserves to be [[Dynamic_Script_Execution_Order#readyState_.22preloading.22|listed as such]]. As always, I welcome input from the community on all the ideas presented here, including this one. But, since the main proposal (async=false) is already being implemented by at least two major browsers, I'm not sure if the tide will be changed or not.

</blockquote>

<blockquote style="background-color:#ddd;">
Also, the suggestion of handling the "preload" and deferred execution via the script tag's `readyState` property is very similar in spirit to the suggestion that was made to explicitly support [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|preloading into cache without execution]]. As I said, either of those two approaches might work, but they both put more of the onus of complexity in managing multiple dependencies on the high-level code (author, script loader, etc). I'm more in favor of this functionality being explicitly built-in natively into the queues. As always, I welcome comments to any side of this discussion.

[[User:Getify|Getify]] 18:35, 15 December 2010 (UTC)
</blockquote>

b) in Gecko and Opera, the default behavior for script-inserted script elements is for them all to load in parallel, but execute serially in insertion order. Technically, this makes it impossible to dynamically load independent script elements and have them execute in "as fast as possible" mode.

As described above, both behaviors are desirable under different circumstances, but each of the two camps provides only one behavior, and no way to straightforwardly achieve the other. This obviously creates a big nightmare interoperability-wise when trying to provide a general script loader cross-browser.

Since it is observed that the behavior in (a) is more detrimental (race-condition wise) for the case where dependencies exist, script loaders like LABjs had to find some way around this problem while still attempting the best possible parallel loading performance. However, the trick used is hacky and not completely reliable -- yet it is the best way to solve the use-case in <s>IE and </s>Webkit.

For Gecko/Opera, the concession was just (silently) made that the lesser-common use case of "as fast as possible" wasn't possible, but degraded fine to "insertion order execution", while keeping the parallel loading benefits.

<blockquote style="background-color: #EEEEEE">
Gecko's strict execution order creates dependencies between scripts which are unrelated and prevents the ability mitigate the impact of server outages / network latency. This is exacerbated by the fact that Gecko, unlike IE and WebKit, provides no mechanism to <b>remove</b> scripts from the execution queue.

Consider the case where JSONP is used to provide auto-completion. The user types "hello" and the JSONP request is made; however, the "currently" loading script is out-of-date as soon as the user modifies his search to "hello world". Gecko's algorithm requires the out-of-date request load and execute before the second request.
</blockquote>

Recently, Gecko landed a [http://hg.mozilla.org/mozilla-central/rev/a60414d076b5 patch] to the trunk that stopped Gecko's existing behavior of preserving execution order, making script-inserted script elements now execute in "as fast as possible" mode similiar to IE/Webkit. Unfortunately, the "workaround" used in IE/Webkit (described in the next section) for dealing with parallel loading and execution-order dependencies does not work in Gecko, which means presently the use-case in question is now broken in Gecko trunk/FF4 nightlies.

Moreover, Webkit recently landed a [http://trac.webkit.org/changeset/67245 patch] to the trunk that stopped Webkit's non-standard but long-held behavior (also used in the "workaround" described in the next section) of loading into cache script resources with an unrecognized "type" value, but silently not executing them. This behvaior (while hacky) is central to being able to address the use-case in question in Webkit, so at present, Webkit nightlies are now also entirely broken on the use-case (though in a different way than Gecko).

Both the Gecko change and the Webkit change are well-intentioned, as they are bringing the respective browser more in line with the HTML spec. However, what's really been demonstrated is that the HTML spec is not properly handling this use-case, and so the goal is not to address the browser issues raised with more awkward hacks, but to address the shortcomings of the spec first, and then encourage all browsers to adhere to such.

<blockquote style="background-color: #EEEEEE">
Considering Internet Explorer's readyState implementation provides a means of both parallel loading and preserving execution order can be achieved, perhaps its "readyState" property and onreadystatechange event should be included.
</blockquote>

=== Current Usage and Workarounds ===
To work around the limitation in IE/Webkit(prior to the above noted patch) of not being able to rely on script order execution for parallel loaded scripts, a "preloading" trick was developed. This trick relied on non-standard (but long-held) behavior in these browsers that a script-inserted script element with an unrecognized "type" value (such as "script/cache") would be fetched/loaded, but would not execute. This had the effect of loading the resource into cache, and then firing the "load" handlers to let the page know when the resource was completely in cache.

Assuming that the resource was served with proper caching headers, and was in fact in the cache, it could then be executed (nearly) immediately when it was the proper execution order time by re-requesting the same resource via another script-inserted script element with the proper "text/javascript" type value, pulling the resource from the cache and executing it, without another server round-trip.

Of course, the assumption of proper cache headers is a huge one, and not at all reliable. Some recent estimates by performance optimization specialists have suggested as much as 70% of scripts across the internet are not served with proper caching headers, which means that such scripts would be completely ineffective if loaded using this (or a similar) technique. The script resource would end up being loaded completely a second-time, and the "near immediate" execution would obviously be false, and thus race conditions would ensue.

It's important to note at this point that the new <link rel=prefetch> facility has been suggested as a better workaround, but it suffers the same ill-fated assumption of script cacheability. Still others have suggested "new Image().src=..." or the [http://www.phpied.com/preload-then-execute/ <object> preloading trick] suggested by Stoyan Stefanov. Again, these tricks unwisely assume cacheability, for the "preloading" trick to solve the use-case in question.

=== At Risk ===
Currently, there are several large/popular web sites which are either currently (or who intend to soon) use LABjs in such a way as to run afoul of the new Gecko and Webkit behavioral changes with LABjs failing to operate properly. It's important to note that the problems of race conditions can be subtle and hard to detect, and so merely loading up such sites and failing to observe overt failure is not sufficient.

Sites which are known to have LABjs loading techniques in place with currently broken (or susceptible to such breakage in the near future) behavior are:

* [http://twitter.com Twitter]
* [http://zappos.com Zappos]
* [http://vimeo.com Vimeo]
* [http://mefeedia.com MeFeedia]
* [http://blog.getify.com Getify Solutions blog (my blog)]
* [http://flensed.com flensed Flash+JavaScript browser shims (cross-domain Ajax, cross-browser cookies, etc)]

Rather than getting hung up in the syntax of usage in LABjs that is or is not going to break, it's best to just think of the problem this way:

Does a site need to load more than one script, at least one of which comes from a remote domain location (like a CDN), and for which among the scripts there's at least one execution-order dependency among them? If so, then that site is susceptible to the current/future breakage if the HTML spec (and browsers) do not address this use case.

A common example (in use on many sites) of such might be loading:

* jQuery from the CDN
* jQuery-UI from the CDN
* plugins and usage code in one or more local files
* Google Analytics from the Google domain

Note that the emergence of popular script frameworks and their hosting on public CDN's is leading to more and more sites loading scripts from both local and remote locations, and also to loading more files that have dependencies (rather than the practice of concat'ing all files into one file to avoid dependency issues).

Any site which fits a profile like the above, and which might currently (many do), or in the future want to, use a script loader to improve their loading performance, will fail to achieve what they want cross-browser and in a performant way, if the HTML spec (and browsers) do not address the use case.

=== Benefits ===
The benefits of addressing both behaviors directly (without "preloading" tricks and bad assumption reliance) have been implied in the above discussion, but in short are:

a) clear and simplified code for script loaders, which leads to easier use by authors of more pages, which in turn leads to better web performance (as demonstrated clearly by intelligent script loading techniques as compared to just simple <script> tags in HTML markup)

b) full access to either/both of the execution-order behaviors (as the author sees fit), regardless of browser

c) avoiding reliance on bad assumptions (like cacheability) as a sufficient way to address the use-case

=== External Discussions of this Feature ===

* <cite>[http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html W3C public-html email thread]</cite>

* <cite>[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 W3C Bug #11295]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=620852 Mozilla Bug #620852]</cite>

* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>

* <cite>[http://hsivonen.iki.fi/script-execution/ HTML5 Script Execution Changes in Firefox 4 Beta 7]</cite>

* <cite>[http://blog.getify.com/2010/10/labjs-w3c-brief-update/ LABjs and W3C... brief update]</cite>

* <cite>[http://blog.getify.com/2010/10/ff4-script-loaders-and-order-preservation/ FF4, script loaders, and order preservation]</cite>

== Proposed Solutions ==

=== My Solution ===
The current proposal most well supported from the email discussion thread, and the one which I feel makes most sense, is described here.

The HTML spec already defines the "async" attribute for parser-inserted script tags, which when set to "true", changes their execution order behavior to be like script-inserted script-elements (in IE/Webkit), which is that they load in parallel and execute "as fast as possible" (ostensibly because the author is expressing no dependencies between multiple such "async"-marked scripts). Parser-inserted script elements without "async" (or with it set to false) behave as before and expected, which is that they load in parallel but execute in order.

However, the HTML spec does not define the "async" property (or any such behavior) for script-inserted script nodes (such as those created by a script loader). Instead, the spec implies that "async=true" like behavior is always true for such script-inserted script elements.

What is proposed is:

a) Script-inserted script elements should have (and respect the value of) an "async" property which is basically identical to the "async" attribute for parser-inserted script elements. That is, script elements with the "async" property set to "true" will behave accordingly, as will script elements with the "async" property set to false.

Essentially, the proposal is to mirror the "async" attribute behavior of parser-inserted script elements as an "async" property on script-inserted script elements. This has the benefit of using an existing facility and extending it (from current spec) in a way that is sensisble and symmetric with its current definition.
<blockquote style="background-color: #EFEFEF">
The scriptgroup or `readyState` alternate proposals allow for dependency management to be done in high-level code. The singular syncrhonized execution queue proposed here introduces artificial dependencies, undermining some of the benefits dynamic script loading provides.
</blockquote>

<blockquote style="background-color: #ccc;">
It's important to note that `async=false` scripts will load in a separate queue from `async=true` scripts. It's not that all scripts will now be forced into this insertion-order-execution queue. An author (or script loader) can chose which queue to put a script loading into based on the needs of the page and the resource. If I have a few scripts that are unrelated to each other and the main page (like Google Analytics, social sharing buttons, etc), I'll load those via `async=true`. For other scripts, where order matters for dependency sake, I'll use `async=false`. I think having both those queues available to high-level code is enough control over loading to serve the majority of use-cases pretty well.
<blockquote style="background-color: #EFEFEF">
If at any point these services begin dynamically loading `async=false` scripts of their own, they will begin blocking. This can lead to unexpected behavior of existing code as third-party libraries and services change. It would seem the specification should provide a means by which this blocking can be isolated to dependencies defined by the author and ordered execution not introduce conditions that allow unrelated libraries to affect this.
</blockquote>
</blockquote>

b) Furthermore, to aid in "feature-detection" of such new behavior, the proposal is to have the default value for the "async" property of script-inserted script elements be "true" (and of course the associated behavior thereof).

There are two major benefits to (b). One is that it provides a way to feature test such new behavior by not just looking for the existence of the "async" property on script elements, but specifically that the default value is "true" (which is opposite of what it would currently/normally be). Secondly, defaulting to "async=true" behavior for script-inserted script elements would preserve the default behavior of IE and Webkit, meaning there'd be less of a chance of breaking existing web content in either of those two browsers.

It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.

==== Proposal Amendment: Need Attribute/Property Semantic Inconsistency ====
In order to achieve consistency between the semantics of how the parser-inserted script element's `async` attribute and the script-inserted script element's `async` property behave, a slight change needs to be made to the value parsing/interpretation for parser-inserted script elements' `async` attribute.

If a parser-inserted script element has the `async` attribute present, but its value is exactly "false" (or any capitalization thereof), the script element should behave EXACTLY as if no `async` attribute were present.

If the attribute is present and either has no value, or has any other value except "false" (for instance, "true" or "async"), then it should be interpreted to be turning on "async" for that element.

Because it is highly unlikely (and indeed, quite irrational) that any existing web content is doing `async="false"` in HTML markup and yet still expecting "async" behavior to be turned on, it is pretty unlikely that this minor interpretation change will cause backwards-compatibility issues.
[[User:Getify|Getify]] 03:05, 22 December 2010 (UTC)

==== Proposal Amendment: Events ====
In addition to standardizing how scripts load and execute, it's also important to standardize the load and error events, and under what circumstances they fire, etc. Without reliable load/error events, the main proposal is not reliable and is thus unhelpful for the use-case.

A script-inserted script element must fire the "load" event only once, when:

a) immediately after the resource finishes loading, but before parsing/execution, AND

b) the script element loads any non-empty content (that is, it was a successful HTTP request), AND

c) the script element has either loaded from the remote location, or is loaded from the brower cache

Specifically, the script "load" event must come immediately between the script element finishing loading and the script element being parsed/executed. If the script resource successfully loads, nothing should interrupt the sequence of fininshing loading, the "load" event firing, and the script being parsed/executed.

A script-inserted script element must fire the "error" event only once, when:

a) immediately after a loading failure for the resource is detected (that is, an HTTP error received, such as 404, 500, 503, etc).

Either the "load" or "error" event, but not both, will fire, and only once, for every script-inserted script element.

NOTE: "load" and "error" events on script-inserted script elements must fire synchronously to ensure event reliability.

A case may be made for adding the "load" and "error" events as described here to parser-inserted script elements as well.

==== Processing Model ====
Script inserted script elements will have an "async" property that defaults to "true". If the author does not change the value, all such requested script loadings will be in their own "queue" and will default to "as fast as possible" execution behavior. For any script elements that the author sets "async=false", those scripts will load in a separate "queue", and will execute in insertion order only. Again, these two "queues" will operate strictly independent of each other.

==== Processing Model Details (without the event amendment) ====

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node.

When a previously-created script element node loses its parser-insertedness, if the element doesn't have the async content attribute, set the force-async flag to true and false otherwise.

When a script element node obtains the async content attribute (via setAttribute, setAttributeNode, setAttributeNS, by the fragment parser or the XSLTProcessor adding the attribute, etc.), set the force-async flag to false. (Note that calling removeAttribute("async") doesn't modify the force-async flag.)

The async IDL attribute must behave as follows:
* Upon setting, set the force-async flag to false and then reflect the async content attribute.
* Upon getting, if the force-async flag is true, return true. Otherwise, reflect the async content attribute.

In step 13. of http://www.whatwg.org/specs/web-apps/current-work/#running-a-script before the case "If the element has a src attribute" add a case:
If the script has a src attribute and the async IDL property getter returns false,
The element must be added to the queue of ordered script-inserted external scripts of the Document of the script element at the time the running a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run these steps:
# If the queue of ordered script-inserted external scripts is empty or the first script in the queue of ordered script-inserted external scripts has not been fetched yet, abort these steps.
# Execute the first script in the queue of ordered script-inserted external scripts.
# Remove the first script from queue of ordered script-inserted external scripts.
# Goto step #1.

Modify step 5 of http://www.whatwg.org/specs/web-apps/current-work/#the-end to say:
Spin the event loop until the set of scripts that will execute as soon as possible is empty and the queue of ordered script-inserted external scripts is empty.

==== Limitations ====
The two behaviors being identified solve either the case where no dependencies exist, or where a linear dependency chain exists (and which the script elements can be requested to execute in that order). It is possible that some authors have a more complex non-linear dependency chain that they would like to express. This would obviously require a much more complex API and spec change, and since that use-case has not (yet) surfaced as a particularly main-stream request, I believe it would be overengineering to try to address it with this proposed change set.

In addition, it's been duly noted that it's undesirable (and potentially confusing/problematic) to intentionally build in the inconsistency of having the "async" attribute (for parser-inserted scripts) and the "async" property (for script-inserted scripts) have different default values ("false" for the attribute, "true" for the property).

It's also been a point of discussion whether or not such a spec change has enough "carrot" to entice the browser vendors (namely IE and Webkit) to implement the behavior. Moreover, there's been some concern that if the default value for the "async" property were made to be "false" (like the attribute) to be more consistent and conservative, then it would possibly give the perception to IE and Webkit of "losing" some performance to cut out their default "as fast as possible" behavior.

=== Alternate Proposals ===
One early proposal on the email list was to introduce an entirely new property like "ordered" which an author could add to a script-inserted script element to instruct the browser to put it into the queue of execution-order-preserving script loadings. While such a property would address the use case, it introduces another property and thus more complicates the issue. It also fails to address the current spec inconsistency (which is confusing to new comers) that "async" is not a present/respected property in mirror of the attribute of the same name.

Another suggestion was a "waitFor" property that would be added to script elements and would specify a list of one or more DOM id's of other script elements that the current script should "wait for" in terms of execution. Again, this would solve the use case, but in a more complicated way, and there are concerns that it would be too confusing for the normal use-case.

Several suggestions have come in the form of creating explicit "preloading" (similar to <link rel=prefetch>), but as described above, "preloading" to solve this use case is a non-ideal hack and highly susceptible to breakage if the script fails to be sent with proper caching headers.

It's also been suggested that since this type of behavior is somewhat complicated, it may be better to intentionally obfuscate or complicate any such facility in the HTML, so as to make the barrier-to-entry rather high and force users to know what they are doing before doing it.

It's been suggested that "defer" already preserves execution order. However, "defer" is only defined for parser-inserted scripts, and thus is not applicable to the use-case in question from an on-demand point of view. Also, "defer" scripts explicitly way for DOMContentLoaded, even if they're ready to execute sooner. So this is less than desired.

Yet another proposal is a "document.executeScripts()" API, where an author can specify multiple sets of scripts that can load in parallel and it will enforce their execution order. A variation on that same idea was to use the "importScripts" from the Web Workers spec, however "importScripts" is synchronous (undesirable performance wise, obviously). The main downside (besides extra API complication) to "document.executeScripts()" is that there seem to be quite a few script execution properties/behaviors (including "document.currentScript" and charset override) which would have to be duplicated into this API facility.

==== "Script Group" element ====
One recent alternate proposal bears some special consideration, as it seems like it might be a decent option (although certainly more of a radical change for the spec and for browsers to implement). But it has the appearance of being pretty straightforward and semantic for authors to use, perhaps even more so than using "async".

The proposal is to create a new HTML element, called perhaps <scriptGroup>, <collection>, etc. Specifically, this element must be able to be inserted wherever a <script> element can currently be inserted. The "script group" element is intended to signify that all script elements added to it must perserve insertion execution order. This element wouldn't have much (but still some, explained in a moment) meaning in a parser-inserted context, since parser-inserted scripts already preserve order among themselves.

An advantage of the "script group" element would be to give a direct and easy way to attach event listeners ("load" and "error") to the entire group, rather than having to internally track events for each element if all you care about is the final "load" event, for instance. In the case of event handling, the "script group" element would have perhaps some benefit even in parser-inserted (markup) context.

The element would need to have an "id" property, and possibly attributes for "load" and "error" events.

A variation on how to look at this proposal is that a "script group" element could have an attribute/property on it (perhaps called "ordered") which would allow the group to either be order preserved or not. This would make the "script group" element much more useful in the parser-inserted context, as it would sort of be a shortcut to setting "async=true" on all the child script elements.

The "script group" element might look like this:

<scriptGroup id="group1">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

Or, with the "ordered" attribute to explicitly control ordering behavior for the group:

<scriptGroup id="group1" ordered="true">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

<scriptGroup id="group2" ordered="false" onload="alldone();">
<script src="baz.js"></script>
<script src="far.js"></script>
<script src="zab.js"></script>
</scriptGroup>

While the "script group" element is definitely more complicated to define and implement, it does have some semantic advantages for authors, and it also would significantly reduce the internal complexity of script loaders like LABjs. It would give authors (either directly or through script loaders) the flexibility to group scripts together into one of the two aforementioned behaviors (execution "as fast as possible" or "in insertion order"), and to easily access both behaviors in the same page.

==== Explicit support for "text/cache" MIME type behavior ====
Yet another alternate proposal has been suggested in the [[Talk:Dynamic_Script_Execution_Order]] thread.

Essentially, the proposal is that <script> tags directly support being declared with a `type` value of "text/cache". The behavior would be that the script resource is fetched, as the load events fired, as normal, but that the script itself would not be executed. Then later, at the desired time, the script in that element could be executed by changing the `type` value from "text/cache" to "text/javascript".

The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.
<blockquote style="background-color:#eee">
And does the onload event fire again after the script executes? <br/>
Or only when it's loaded? <br/>
Both seem to violate current `onload` semantics.
[[User:Serverherder|Serverherder]] 20:27, 15 December 2010 (UTC)

<blockquote style="background-color:#ccc">
As far as I'm concerned, I think the "load" event should happen immediately after a script loads, but before it executes, as I spell out in the [[Dynamic_Script_Execution_Order#Proposal_Amendment:_Events|Events proposal ammendment section]]. [[User:Getify|Getify]] 20:33, 15 December 2010 (UTC)
</blockquote>

</blockquote>

==== readyState "preloading" ====
Per the suggestion/comment added to the above [[Dynamic_Script_Execution_Order#Current_Limitations|Current Limitations]] section, it's been suggested that IE's current behavior with respect to the `readyState` property can adequately serve the use-case in question. This alternate proposal is very similar in spirit to the [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|previous section on explicit support for "text/cache"]] mime-type value.

The idea is that IE will begin fetching into the cache a script resource as soon as the `src` attribute of the dynamic script element is set. But IE will not execute the script (even if it finishes loading) until the script element is added to the DOM. However, the `readyState` property of the element, combined with the `onreadystatechange` handler listening for changes, can detect when the script has finished loading, by receiving the "loaded" value.

In this way, a script loader could "preload" a set of scripts all in parallel, but control their execution order by delaying the appending of the element to the DOM until execution is desired.

'''Update''' [[User:Getify|Getify]] 14:10, 20 December 2010 (UTC)

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

This seems to be the spec stating that browsers may do what IE's behavior on scripts does, which is to start fetching the resource once the `src` property is set, but not execute it until the script element is inserted into the DOM.

It would seem then that browsers could/should be petitioned to consider implementing this suggestion, perhaps taking the `readyState` implementation from IE as guidance. While I'm still not sure that this would be my preferred method of solving the overall use-case in discussion on this page, it would be an option for such, and it would also help other use-cases, such as those being discussed in this W3C public-html thread:

[http://lists.w3.org/Archives/Public/public-html/2010Dec/0174.html Need to: "preload" CSS and JS]

==== Do nothing and encourage vendors implement the existing suggestion ====
As noted by Getify above, the spec all ready makes the suggestion that a script's SRC attribute be fetched immediately upon assignment.

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

While not explicit, it seems the specification all ready deals with the use-case this is hoping to achieve: It makes parallel loading scripts '''optional'''. Execution order can all ready be handled by loaders using onload-chaining. Therefore, parallel loading can be achieved, but only in browsers that have chosen to implement the suggestion.

Given this, the discussion can shift to:
# Should the suggestion be changed to a mandate?
# Should the specification include a way to '''force''' parallel loading?
# Should we be petitioning vendors, not the the W3C, to implement the existing suggestion?

[[Category:Proposals]]

Script Execution Control

2011-02-14T00:24:20Z

Getify: /* External Discussions of this Feature */

Script Execution Control

2011-02-14T00:23:33Z

Getify: adding link to "ControlJS" blog posts

Script Execution Control

2011-02-13T23:23:18Z

Getify: link edits

Script Execution Control

2011-02-13T23:18:47Z

Getify: creating initial page

Talk:Dynamic Script Execution Order

2010-12-24T00:50:45Z

Getify: /* response */

Please discuss the proposal here. All informal feedback is welcomed, and when it's appropriate, please add content to the main page.

== What about CommonJS / RequireJS? ==

I'm not sure we need to complicate the HTML or browser engines in order to satisfy the advanced use cases. To me it seems that the JavaScript langauge itself could abstract the requirements and let the browser vendors implement whatever solution they see fit. Specifically, if JavaScript provided the define() and require() calls proposed in the CommonJS "specifications" (and implemented by [http://requirejs.org/docs/api.html RequireJS], [http://svn.dojotoolkit.org/src/dojo/trunk/_base/_loader/loader.js dojo (trunk)], and others *Yabble?), then browsers could just load and evaluate scripts as fast as possible without regard to script execution order.

This would solve all of the problems except for the current inability to use loaders like LABjs in FF4 or webkit. To solve that problem, we should consider keeping the existing functionality or triggering the deprecated functionality when needed.

--[[User:Unscriptable|Unscriptable]] 01:29, 2 November 2010 (UTC)

=== Response ===

This is a valid point except that it assumes that all code that needs to be loaded is "modular"... in fact, most code on the internet that needs to be loaded is NOT modular, and instead requires particular ordering when being loaded... for instance, "jquery" and "jquery-ui" -- jQuery must be run before jQuery-UI is loaded and run.

The spirit of this proposal is to add the facility to native browser (rendering engine, specifically) behavior, such that any and all existing content is able to be loaded (even with dependencies and order) without modification.
<blockquote style=background-color:#eee>
Are we trying to codify how one would implement this HTML dynamically so I can achieve parallel loading but retain dependency that is inferred in the order?

<blockquote style="background-color: white">
<script src="jquery.js"> </script> <br/>
<script src="jquery-ui.js"> </script>
</blockquote>

If so, we must consider the case in which the dependency itself loads additional code which the discussions around `async=false` or even text/cache do not account for.
[[User:Serverherder|Serverherder]] 19:23, 15 December 2010 (UTC)
</blockquote>

=== Dependent code should be modular ===

I completely agree, 99% of JavaScript in use today is NOT modular, but that's arguably because there was no built-in support to make it modular (IMHO, YMMV, RTFM, BBQ, ROFL). But that doesn't mean there aren't dependencies that span script files / script nodes. I don't know how many sites would be broken (or if there is any way to determine how many sites would be broken) if/when the latest browsers started loading and evaluating script-injected scripts out of order. It's not just LABjs-based sites. I'll bet many dojo and YUI sites will break, too (although I don't know this for a fact because I don't know exactly how their dynamic script loaders work).

'''''In any case, breaking existing sites is a BAD IDEA. :) There should be some way to allow LABjs and other dynamic script loaders to continue to work.'''''

The part I don't agree with in the proposals is that it should be the job of HTML and/or the browser engine to manage dependencies. Specifically, I am talking about the scriptGroup element and the "waitFor" attribute. The "async" attribute may be the right level: it appropriates only general heuristics to the browser: ''load these scripts whenever you like, but load these other scripts in this order''.

Detailed dependency management belongs in the modules, though. This is how it's done in most environments / languages: import statements, include statements, etc. It's no different in JavaScript, if a developer wants to take advantage of some code in another module, she/he should import it into their current module. This should be the model moving forward. It's not hard, it's not un-web-like, and it's already being done.

Existing code can be made to work modularly, too:

1. Identify modules and wrap them with a define() method.
2. Identify dependencies using either the [http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition Asynchronous Module Definition] format or the CommonJS synchronous format

async format:
<pre lang="javascript">
define(['dependency1', 'dependency2'], function (dependency1, dependency2) {
/* this is the factory function, return the module inside here */
return { /* some object, but could also be a constructor or a function */ };
});
</pre>
sync format:
<pre lang="javascript">
define(function (require, exports, module) {
/* this is the factory function, require dependencies and return the module inside here */
var dependency1 = require('dependency1');
var dependency2 = require('dependency2');
return { /* some object, but could also be a constructor or a function */ };
});
</pre>
In the async case, the browser may employ whatever method it sees fit (e.g. parallel) to download the dependencies since the code inside the factory function won't execute until all of the dependencies are loaded and evaluated. In the sync case, the browser has no choice but to download and evaluate the dependency before continuing code execution. It's conceivable that the browser could find and asynchronously pre-fetch the inline require()'ed dependencies in the sync case. (RequireJS doesn't quite do this. Instead I believe it finds the inline require() calls and converts the module to an async module.)

'''''So, in short: don't break LABjs (or any other script loaders), but don't extend the spec to manage dependency management from HTML.'''''

--[[User:Unscriptable|Unscriptable]] 01:29, 2 November 2010 (UTC)

== Response #2 ==

The cat's already out of the bag... we've got a dozen+ years worth, hundreds of millions of javascript files out there, which are NOT modular, and will not be modified to be modular.

If we're talking about either trying to change all the JS on the web to be modular, or trying to extend the HTML markup spec to include a better facility for accomodating the existing script content, I think the former is idealistic and "correct" but the latter is realistic and "right".

A modular loading system will only work for modular code, but a general loading mechanism in HTML (like the <script> tag) can load both modular and non-modular code, which is why that more general mechanism is what's in HTML right now and not some more specialized loading API that only loads a small percentage of JavaScript code out there.

The <script> tag has worked fine forever, and there's been no real big push to do away with it in favor of having all loading handled by JavaScript -- in fact, that would be impossible because if you had no way to load JS onto the page with a <script> tag, then no JavaScript could run on a page to load more code. So I don't agree that we should stop adding functionality to the HTML loading mechanism and only focus on JavaScript.

If we agree that the <script> tag itself is not only required but normative, then I'm not sure why decorating the <script> tag with additional behavior to help it be more powerful is a bad pattern. We've addded "defer" and "async" already. I'm not sure I understand why adding a wrapper tag called "scriptGroup" would be that much different than attributes on the <script> tag?

I also don't think that "scriptGroup" constitutes "dependency management". "scriptGroup" is a semantic way for a web author to express that they want to group a set of scripts together ONLY so far as execution order behavior is concerned. It implies nothing more to it (that "dependency management" would imply) than that.

For instance, consider this: if JavaScript had been built with non-global context and statement level context and sandboxing and such things, we'd have a much more secure JavaScript right now. But just because JavaScript may someday be taught some new tricks in terms of security, that doesn't mean that "now" HTML shouldn't try to help solve the problem. If for instance the <frag> tag can be used to create a sandboxed environment for third-party JavaScript code to run in, this is a much easier way to address the security problem than to suggest we have to wait for ES-Harmony to add extra syntax to the language to accomplish the same thing.

[[User:Getify|Getify]] 02:13, 2 November 2010 (UTC)

== Text/cache solution ==

It seems to me that having a real text/cache script type, or a similar element that fires a load/error event and provides a .text property gets you where you need to be. You could setAttribute("type", "text/JavaScript") or use the text to create a new script element. Or a new style element, or whatever. That puts you in control of when script or CSS is interpreted. With async as the default, you don't need a new ordered attribute as that's easily managed in script.

== "text/cache" response ==

On the surface, this idea sounds like it's pretty similar to <link rel=prefetch> -- in other words, we've already standardized a way to prefetch a resource into cache, and probably in a better way than the hack that I did in LABjs of just relying on it fetching unrecognizable content.

Unfortunately, it still suffers some similar problems to <link rel=prefetch>.

Firstly, if the notion is that you'd use <script type="text/cache"> to prefetch, and then you'd make a second request for the resource with a real <script type="text/javascript> node, it suffers the faulty assumption that the resource was served with proper cache headers.

If we try to avoid the need for the second request by suggesting that you can access the `text` property of the node (and then eval() or inject that code when you want to execute it), this runs afoul of the same-origin policy problem if you requested the script from a non-local domain.

The part of your suggestion that holds water would be if, given a "prefetched" script node that didn't execute yet, I could simply change that node's `type` value from "text/cache" to "text/javascript", and that would explicitly trigger the browser to immediately execute it.

This is an interesting idea. I can see though that it perhaps has some potential complications.

For instance, would the browser have to keep a "hasExecuted" internal flag, so that changing the `type` value would only at most result in one execution? Also, if the script node in question is loaded but not executed, can the page alter the script code (by setting its `text` property) before making the change to the `type` value? In that case, should the browser execute the original code or the modified code? I can see security implications and confusion abounding in that behavior.

Lastly, as mentioned above, this basically copies (in a similar but not exactly identical way) the <link rel=prefetch> behavior. It may be seen as a negative to be trying to step on the toes of <link rel=prefetch>, and also it may be more confusing to the general public as to why you'd use one technique or the other, given their differences being so nuanced.

That having been said, I can see that it's a viable alternate proposal. It's worth adding a note to that section of the main Wiki page and to getting some feedback from browser vendors on if they feel this is a more realistic/suitable solution to the use-case.
<blockquote style="background-color: #eee">
The difference between pre-fetching and this proposal seems pretty clear: Prefetching, if not performed now, will eventually be done once the user explicitly requests the page. while the "text/cache" solution indicates that the resource should load '''immediately''', not during idle time.

<br/>
[[User:Serverherder|Serverherder]] 19:10, 15 December 2010 (UTC)
</blockquote>

[[User:Getify|Getify]] 20:56, 4 November 2010 (UTC)

== RequireJS order support ==

I am the main developer for RequireJS, and just want to voice my support for a solution that works on the script element itself, either by leveraging the async attribute or allowing something like an "order" boolean attribute that would allow specifying a dynamically added script element should be executed in the order that it appears in the DOM. This capability should be something can be capability detected to avoid browser sniffing.
<blockquote style="background-color:#eee">
Why shouldn't dependency management be implemented in high-level code and the browser simply provide a means by which parallel loading can be achieved? As you know, there is a considerable amount of nuance. I'm of the opinion that implementing dependency management in the engine will eventually lead us right back to where we were 10 years ago with inline script tags which provides an easy method for dependency management at the expense of unmanaged blocking and an inability to detect or adapt to errors. <br/>
[[User:Serverherder|Serverherder]] 19:51, 15 December 2010 (UTC)
</blockquote>

There are many scripts on the web today that have implicit dependencies that should be loaded in a specific order, but the application developer will want to use dynamically created script elements for best performance. jQuery plugins that depend on the jQuery script already been executed in the page are a good example.
<blockquote style="background-color:#eee">
Agreed, but I don't believe the proposals allow for proper emulation of the dependency management provided by script tags. Prototype.js, for example, loads its core modules dynamically (using document.write so maybe not the best example...). When prototype.js is included via script tags, ensuing script blocks are free to "depend" on all of these modules; Dynamically creating a dependency on prototype.js by loading both with the `async=true` property will fail since prototype.js won't be able to "jump the queue" and add insure its core modules load before its extensions. <br/>
[[User:Serverherder|Serverherder]] 19:51, 15 December 2010 (UTC)

<blockquote style="background-color:#ccc">
I have to admit, you raise a valid point with respect to that common usage. The YUI model (where the framework is responsible for all loading) is perhaps the more appropriate model to move toward, though. Or, the framework doesn't auto-load its own dependencies at all. In either case, I think it's cleaner to have one loading mechanism in play rather than two or more competing ones, because as you point out, this is going to get messy. I still am not sure this means that the async=false proposal is lacking, because as I think about how complicated such a split loading would be with your `readyState` proposal, that seems even worse/more complicated to me. [[User:Getify|Getify]] 20:06, 15 December 2010 (UTC)
</blockquote>
<blockquote style="background-color:#eee">

I would not argue '''against''' a global queue for synchronized execution, I just think the usefulness of such a construct declines as scripts that "I don't care about" are added. It's my opinion the spec should provide the ability for high-level code to implement similar constructs, regardless of how complex it may be to do so. <br/>
<br>
That being said, I don't think it's any more complicated than existing models. Here's a demonstration of an [http://digital-fulcrum.com/executionorder/ IE-only parallel-loading, synchronously-executing script queue] implemented in 40 lines of code. It tests both cached and un-cached scripts (from the LABjs test suite) and has been tested and found to be working in IE6-8.
<br>
[[User:Serverherder|Serverherder]] 01:52, 16 December 2010 (UTC)
</blockquote>
</blockquote>

- James Burke

== Vendors Should Implement the Existing Suggestion ==

Since the spec all ready includes a suggestion to download resources when the SRC attribute is set, parallel loading is an option the '''vendor''' chooses to implement and not something a script loader should be able to require. Vendors that don't implement the suggestion will run the risk of being less performant in these situations. That, however, is '''their''' choice to make as the spec suggests. If the benefits of parallel loading dependencies are so great, users will opt for this in their choice of agent or vendors can adopt the existing mechanism.

== The Current Suggestion Should be Changed to a Mandate ==

The spec is pretty clear on why it chose to make this optional. If dependent script loading is so common that browsers that adopt the suggestion enjoy considerably better performance, the user will eventually decide to opt for those implementations. On the other hand, if it is more common that scripts are created and never inserted, leading to wasted bandwidth and clogged fetching queues, the converse will occur. Either way, by making it optional, the spec hedges its bet and is more prone to be future-proof as the habits of script developers evolve.

== Modify the specification so parallel-loading is configurable ==
The specification expresses the reasons parallel loading should not be done. To this point, allowing developers a means to '''require''' resources be downloaded in parallel is in direct opposition to the spec's all ready stated position. To this end, I see no purpose for async=true: A browser that hopes to be highly performant should implement the spec's suggestion to improve performance. Developers should not be able to circumvent the vendor's attempt to be conservative in its use of bandwidth simply to achieve ordered execution.

=== response ===
Nothing about this proposal requires any parallelism that the browser wouldn't already afford. The spirit of this proposal is not about loading behavior, but about execution order.

The spec says nothing about the parallel loading, nor do I think it should necessarily. All modern browsers HAVE in fact implemented parallel loading for all scripts, regardless of async or not. And I think this is a good thing. But it has nothing to do with `async` or my proposal to make the definition of `async` symmetric/consistent between markup script elements and dynamic script elements.

The spec already defines that `async` is specifically to create unblocking of the page's resource loading AND "as soon as possible" execution of the script. But it only defines this for parser-inserted (markup) script tags. I think this is short-sighted, because I think a script-loader should be able to opt into either ordered or unordered execution in the same way that markup script elements can. That's really all the main proposal is about.

<blockquote style="background-color:#EEE">
Script loaders can all ready choose ordered execution: chain the onload events. The issue is that vendors have chosen '''not''' to adopt the specification's suggestion. The high priority vendors place on performance suggests this was not done consciously. Instead of advocating WHATWG for additions to the spec, I think we may be better off advocating vendors implement the spec's suggestion. The existing implementation of parallelism for parser-inserted scripts suggests vendors would be willing to do so and the existing lack of support is merely an issue of communication.

At its core, the existing suggestion to retrieve upon src assignment is not altogether different than the eager-fetching performed for parser-inserted scripts. The risk still exists that the browser download a script that is never actually executed. For example, below a bunch of script tags, the HTML may contain a closing comment tag (-->) and one of the scripts doc.write("<\!--"). Another risk is that the eager-fetching clog the fetch queue, delaying the download of any scripts included via document.write(). Vendors have '''chosen''' to assume this risk though, since its probability is low and the benefit high.

Likewise, vendors can calculate the risk/reward for script-inserted scripts and will likely make the same decision -- they implement this exact behavior for images. Script loaders should respect the fact that a vendor has consciously chosen '''not''' to support parallelism for script-inserted scripts. Providing a means by which this decision can be circumvented undermines their choice. I believe it was in that spirit the specification leaves eager fetching script resources as a suggestion.

<blockquote>

<blockquote style="background-color:#ccc">
I think you still miss the pragmatic point here. I'm not disagreeing with you in theory, but in practice, the hard-nosed approach you suggest would spell death for any script loader. That's not a chance I'm willing to take.

When a developer uses a script loader that claims it is "The Performance Script Loader" (as LABjs does), and they test in some latest-version browser (whether that be FF, Safari, Chrome, IE, or Opera) and the performance is terrible (worse than before they installed LABjs), they're not going to say, "Well, I'll just keep LABjs in there and hope those browsers fix this quickly".

This is tail-wagging-the-dog mentality, and it ignores the reality: people will almost always chose the path of least resistance. If they try a script loader, and it gives them worse performance than before, they'll simply take it out. They may complain about it once in a tweet, but they won't take a stand against the browsers to the detriment of their own site and their own users, and they won't tell all their users to switch to another browser in protest.

And worse, for LABjs, the path of least resistance may very well mean that if performance is important to them, they'll just pick some other loader, which has more hacks in it. As long as they get what they want, which is reliable and pretty good performance, they'll be happy. And it will totally have been lost on them that the battle for web standards was just dealt a blow by their actions. General web page authors do not care to fight that battle on behalf of LABjs. So, LABjs must fight that battle under the covers.

I understand your perspective, but I can say as the maintainer of a tool like LABjs that cares about keeping its relevancy for "survival", I won't take an action that I know is likely to cause a decline in the usefulness of my tool. Instead, I will take a more cautious, slow-to-change approach, while at the same time feature-testing for the new standards and using them if available. Only after a long time of the new feature-testable stuff being present will I consider removing the legacy stuff. This is a strategy I think almost every framework/lib maintainer would echo support for.

[[User:Getify|Getify]] 00:50, 24 December 2010 (UTC)
</blockquote>

[[User:Getify|Getify]] 21:39, 23 December 2010 (UTC)

Talk:Dynamic Script Execution Order

2010-12-24T00:50:04Z

Getify: /* response */

Please discuss the proposal here. All informal feedback is welcomed, and when it's appropriate, please add content to the main page.

== What about CommonJS / RequireJS? ==

I'm not sure we need to complicate the HTML or browser engines in order to satisfy the advanced use cases. To me it seems that the JavaScript langauge itself could abstract the requirements and let the browser vendors implement whatever solution they see fit. Specifically, if JavaScript provided the define() and require() calls proposed in the CommonJS "specifications" (and implemented by [http://requirejs.org/docs/api.html RequireJS], [http://svn.dojotoolkit.org/src/dojo/trunk/_base/_loader/loader.js dojo (trunk)], and others *Yabble?), then browsers could just load and evaluate scripts as fast as possible without regard to script execution order.

This would solve all of the problems except for the current inability to use loaders like LABjs in FF4 or webkit. To solve that problem, we should consider keeping the existing functionality or triggering the deprecated functionality when needed.

--[[User:Unscriptable|Unscriptable]] 01:29, 2 November 2010 (UTC)

=== Response ===

This is a valid point except that it assumes that all code that needs to be loaded is "modular"... in fact, most code on the internet that needs to be loaded is NOT modular, and instead requires particular ordering when being loaded... for instance, "jquery" and "jquery-ui" -- jQuery must be run before jQuery-UI is loaded and run.

The spirit of this proposal is to add the facility to native browser (rendering engine, specifically) behavior, such that any and all existing content is able to be loaded (even with dependencies and order) without modification.
<blockquote style=background-color:#eee>
Are we trying to codify how one would implement this HTML dynamically so I can achieve parallel loading but retain dependency that is inferred in the order?

<blockquote style="background-color: white">
<script src="jquery.js"> </script> <br/>
<script src="jquery-ui.js"> </script>
</blockquote>

If so, we must consider the case in which the dependency itself loads additional code which the discussions around `async=false` or even text/cache do not account for.
[[User:Serverherder|Serverherder]] 19:23, 15 December 2010 (UTC)
</blockquote>

=== Dependent code should be modular ===

I completely agree, 99% of JavaScript in use today is NOT modular, but that's arguably because there was no built-in support to make it modular (IMHO, YMMV, RTFM, BBQ, ROFL). But that doesn't mean there aren't dependencies that span script files / script nodes. I don't know how many sites would be broken (or if there is any way to determine how many sites would be broken) if/when the latest browsers started loading and evaluating script-injected scripts out of order. It's not just LABjs-based sites. I'll bet many dojo and YUI sites will break, too (although I don't know this for a fact because I don't know exactly how their dynamic script loaders work).

'''''In any case, breaking existing sites is a BAD IDEA. :) There should be some way to allow LABjs and other dynamic script loaders to continue to work.'''''

The part I don't agree with in the proposals is that it should be the job of HTML and/or the browser engine to manage dependencies. Specifically, I am talking about the scriptGroup element and the "waitFor" attribute. The "async" attribute may be the right level: it appropriates only general heuristics to the browser: ''load these scripts whenever you like, but load these other scripts in this order''.

Detailed dependency management belongs in the modules, though. This is how it's done in most environments / languages: import statements, include statements, etc. It's no different in JavaScript, if a developer wants to take advantage of some code in another module, she/he should import it into their current module. This should be the model moving forward. It's not hard, it's not un-web-like, and it's already being done.

Existing code can be made to work modularly, too:

1. Identify modules and wrap them with a define() method.
2. Identify dependencies using either the [http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition Asynchronous Module Definition] format or the CommonJS synchronous format

async format:
<pre lang="javascript">
define(['dependency1', 'dependency2'], function (dependency1, dependency2) {
/* this is the factory function, return the module inside here */
return { /* some object, but could also be a constructor or a function */ };
});
</pre>
sync format:
<pre lang="javascript">
define(function (require, exports, module) {
/* this is the factory function, require dependencies and return the module inside here */
var dependency1 = require('dependency1');
var dependency2 = require('dependency2');
return { /* some object, but could also be a constructor or a function */ };
});
</pre>
In the async case, the browser may employ whatever method it sees fit (e.g. parallel) to download the dependencies since the code inside the factory function won't execute until all of the dependencies are loaded and evaluated. In the sync case, the browser has no choice but to download and evaluate the dependency before continuing code execution. It's conceivable that the browser could find and asynchronously pre-fetch the inline require()'ed dependencies in the sync case. (RequireJS doesn't quite do this. Instead I believe it finds the inline require() calls and converts the module to an async module.)

'''''So, in short: don't break LABjs (or any other script loaders), but don't extend the spec to manage dependency management from HTML.'''''

--[[User:Unscriptable|Unscriptable]] 01:29, 2 November 2010 (UTC)

== Response #2 ==

The cat's already out of the bag... we've got a dozen+ years worth, hundreds of millions of javascript files out there, which are NOT modular, and will not be modified to be modular.

If we're talking about either trying to change all the JS on the web to be modular, or trying to extend the HTML markup spec to include a better facility for accomodating the existing script content, I think the former is idealistic and "correct" but the latter is realistic and "right".

A modular loading system will only work for modular code, but a general loading mechanism in HTML (like the <script> tag) can load both modular and non-modular code, which is why that more general mechanism is what's in HTML right now and not some more specialized loading API that only loads a small percentage of JavaScript code out there.

The <script> tag has worked fine forever, and there's been no real big push to do away with it in favor of having all loading handled by JavaScript -- in fact, that would be impossible because if you had no way to load JS onto the page with a <script> tag, then no JavaScript could run on a page to load more code. So I don't agree that we should stop adding functionality to the HTML loading mechanism and only focus on JavaScript.

If we agree that the <script> tag itself is not only required but normative, then I'm not sure why decorating the <script> tag with additional behavior to help it be more powerful is a bad pattern. We've addded "defer" and "async" already. I'm not sure I understand why adding a wrapper tag called "scriptGroup" would be that much different than attributes on the <script> tag?

I also don't think that "scriptGroup" constitutes "dependency management". "scriptGroup" is a semantic way for a web author to express that they want to group a set of scripts together ONLY so far as execution order behavior is concerned. It implies nothing more to it (that "dependency management" would imply) than that.

For instance, consider this: if JavaScript had been built with non-global context and statement level context and sandboxing and such things, we'd have a much more secure JavaScript right now. But just because JavaScript may someday be taught some new tricks in terms of security, that doesn't mean that "now" HTML shouldn't try to help solve the problem. If for instance the <frag> tag can be used to create a sandboxed environment for third-party JavaScript code to run in, this is a much easier way to address the security problem than to suggest we have to wait for ES-Harmony to add extra syntax to the language to accomplish the same thing.

[[User:Getify|Getify]] 02:13, 2 November 2010 (UTC)

== Text/cache solution ==

It seems to me that having a real text/cache script type, or a similar element that fires a load/error event and provides a .text property gets you where you need to be. You could setAttribute("type", "text/JavaScript") or use the text to create a new script element. Or a new style element, or whatever. That puts you in control of when script or CSS is interpreted. With async as the default, you don't need a new ordered attribute as that's easily managed in script.

== "text/cache" response ==

On the surface, this idea sounds like it's pretty similar to <link rel=prefetch> -- in other words, we've already standardized a way to prefetch a resource into cache, and probably in a better way than the hack that I did in LABjs of just relying on it fetching unrecognizable content.

Unfortunately, it still suffers some similar problems to <link rel=prefetch>.

Firstly, if the notion is that you'd use <script type="text/cache"> to prefetch, and then you'd make a second request for the resource with a real <script type="text/javascript> node, it suffers the faulty assumption that the resource was served with proper cache headers.

If we try to avoid the need for the second request by suggesting that you can access the `text` property of the node (and then eval() or inject that code when you want to execute it), this runs afoul of the same-origin policy problem if you requested the script from a non-local domain.

The part of your suggestion that holds water would be if, given a "prefetched" script node that didn't execute yet, I could simply change that node's `type` value from "text/cache" to "text/javascript", and that would explicitly trigger the browser to immediately execute it.

This is an interesting idea. I can see though that it perhaps has some potential complications.

For instance, would the browser have to keep a "hasExecuted" internal flag, so that changing the `type` value would only at most result in one execution? Also, if the script node in question is loaded but not executed, can the page alter the script code (by setting its `text` property) before making the change to the `type` value? In that case, should the browser execute the original code or the modified code? I can see security implications and confusion abounding in that behavior.

Lastly, as mentioned above, this basically copies (in a similar but not exactly identical way) the <link rel=prefetch> behavior. It may be seen as a negative to be trying to step on the toes of <link rel=prefetch>, and also it may be more confusing to the general public as to why you'd use one technique or the other, given their differences being so nuanced.

That having been said, I can see that it's a viable alternate proposal. It's worth adding a note to that section of the main Wiki page and to getting some feedback from browser vendors on if they feel this is a more realistic/suitable solution to the use-case.
<blockquote style="background-color: #eee">
The difference between pre-fetching and this proposal seems pretty clear: Prefetching, if not performed now, will eventually be done once the user explicitly requests the page. while the "text/cache" solution indicates that the resource should load '''immediately''', not during idle time.

<br/>
[[User:Serverherder|Serverherder]] 19:10, 15 December 2010 (UTC)
</blockquote>

[[User:Getify|Getify]] 20:56, 4 November 2010 (UTC)

== RequireJS order support ==

I am the main developer for RequireJS, and just want to voice my support for a solution that works on the script element itself, either by leveraging the async attribute or allowing something like an "order" boolean attribute that would allow specifying a dynamically added script element should be executed in the order that it appears in the DOM. This capability should be something can be capability detected to avoid browser sniffing.
<blockquote style="background-color:#eee">
Why shouldn't dependency management be implemented in high-level code and the browser simply provide a means by which parallel loading can be achieved? As you know, there is a considerable amount of nuance. I'm of the opinion that implementing dependency management in the engine will eventually lead us right back to where we were 10 years ago with inline script tags which provides an easy method for dependency management at the expense of unmanaged blocking and an inability to detect or adapt to errors. <br/>
[[User:Serverherder|Serverherder]] 19:51, 15 December 2010 (UTC)
</blockquote>

There are many scripts on the web today that have implicit dependencies that should be loaded in a specific order, but the application developer will want to use dynamically created script elements for best performance. jQuery plugins that depend on the jQuery script already been executed in the page are a good example.
<blockquote style="background-color:#eee">
Agreed, but I don't believe the proposals allow for proper emulation of the dependency management provided by script tags. Prototype.js, for example, loads its core modules dynamically (using document.write so maybe not the best example...). When prototype.js is included via script tags, ensuing script blocks are free to "depend" on all of these modules; Dynamically creating a dependency on prototype.js by loading both with the `async=true` property will fail since prototype.js won't be able to "jump the queue" and add insure its core modules load before its extensions. <br/>
[[User:Serverherder|Serverherder]] 19:51, 15 December 2010 (UTC)

<blockquote style="background-color:#ccc">
I have to admit, you raise a valid point with respect to that common usage. The YUI model (where the framework is responsible for all loading) is perhaps the more appropriate model to move toward, though. Or, the framework doesn't auto-load its own dependencies at all. In either case, I think it's cleaner to have one loading mechanism in play rather than two or more competing ones, because as you point out, this is going to get messy. I still am not sure this means that the async=false proposal is lacking, because as I think about how complicated such a split loading would be with your `readyState` proposal, that seems even worse/more complicated to me. [[User:Getify|Getify]] 20:06, 15 December 2010 (UTC)
</blockquote>
<blockquote style="background-color:#eee">

I would not argue '''against''' a global queue for synchronized execution, I just think the usefulness of such a construct declines as scripts that "I don't care about" are added. It's my opinion the spec should provide the ability for high-level code to implement similar constructs, regardless of how complex it may be to do so. <br/>
<br>
That being said, I don't think it's any more complicated than existing models. Here's a demonstration of an [http://digital-fulcrum.com/executionorder/ IE-only parallel-loading, synchronously-executing script queue] implemented in 40 lines of code. It tests both cached and un-cached scripts (from the LABjs test suite) and has been tested and found to be working in IE6-8.
<br>
[[User:Serverherder|Serverherder]] 01:52, 16 December 2010 (UTC)
</blockquote>
</blockquote>

- James Burke

== Vendors Should Implement the Existing Suggestion ==

Since the spec all ready includes a suggestion to download resources when the SRC attribute is set, parallel loading is an option the '''vendor''' chooses to implement and not something a script loader should be able to require. Vendors that don't implement the suggestion will run the risk of being less performant in these situations. That, however, is '''their''' choice to make as the spec suggests. If the benefits of parallel loading dependencies are so great, users will opt for this in their choice of agent or vendors can adopt the existing mechanism.

== The Current Suggestion Should be Changed to a Mandate ==

The spec is pretty clear on why it chose to make this optional. If dependent script loading is so common that browsers that adopt the suggestion enjoy considerably better performance, the user will eventually decide to opt for those implementations. On the other hand, if it is more common that scripts are created and never inserted, leading to wasted bandwidth and clogged fetching queues, the converse will occur. Either way, by making it optional, the spec hedges its bet and is more prone to be future-proof as the habits of script developers evolve.

== Modify the specification so parallel-loading is configurable ==
The specification expresses the reasons parallel loading should not be done. To this point, allowing developers a means to '''require''' resources be downloaded in parallel is in direct opposition to the spec's all ready stated position. To this end, I see no purpose for async=true: A browser that hopes to be highly performant should implement the spec's suggestion to improve performance. Developers should not be able to circumvent the vendor's attempt to be conservative in its use of bandwidth simply to achieve ordered execution.

=== response ===
Nothing about this proposal requires any parallelism that the browser wouldn't already afford. The spirit of this proposal is not about loading behavior, but about execution order.

The spec says nothing about the parallel loading, nor do I think it should necessarily. All modern browsers HAVE in fact implemented parallel loading for all scripts, regardless of async or not. And I think this is a good thing. But it has nothing to do with `async` or my proposal to make the definition of `async` symmetric/consistent between markup script elements and dynamic script elements.

The spec already defines that `async` is specifically to create unblocking of the page's resource loading AND "as soon as possible" execution of the script. But it only defines this for parser-inserted (markup) script tags. I think this is short-sighted, because I think a script-loader should be able to opt into either ordered or unordered execution in the same way that markup script elements can. That's really all the main proposal is about.

<blockquote style="background-color:#EEE">
Script loaders can all ready choose ordered execution: chain the onload events. The issue is that vendors have chosen '''not''' to adopt the specification's suggestion. The high priority vendors place on performance suggests this was not done consciously. Instead of advocating WHATWG for additions to the spec, I think we may be better off advocating vendors implement the spec's suggestion. The existing implementation of parallelism for parser-inserted scripts suggests vendors would be willing to do so and the existing lack of support is merely an issue of communication.

At its core, the existing suggestion to retrieve upon src assignment is not altogether different than the eager-fetching performed for parser-inserted scripts. The risk still exists that the browser download a script that is never actually executed. For example, below a bunch of script tags, the HTML may contain a closing comment tag (-->) and one of the scripts doc.write("<!--"). Another risk is that the eager-fetching clog the fetch queue, delaying the download of any scripts included via document.write(). Vendors have '''chosen''' to assume this risk though, since its probability is low and the benefit high.

Likewise, vendors can calculate the risk/reward for script-inserted scripts and will likely make the same decision -- they implement this exact behavior for images. Script loaders should respect the fact that a vendor has consciously chosen '''not''' to support parallelism for script-inserted scripts. Providing a means by which this decision can be circumvented undermines their choice. I believe it was in that spirit the specification leaves eager fetching script resources as a suggestion.

<blockquote>

<blockquote style="background-color:#ccc">
I think you still miss the pragmatic point here. I'm not disagreeing with you in theory, but in practice, the hard-nosed approach you suggest would spell death for any script loader. That's not a chance I'm willing to take.

When a developer uses a script loader that claims it is "The Performance Script Loader" (as LABjs does), and they test in some latest-version browser (whether that be FF, Safari, Chrome, IE, or Opera) and the performance is terrible (worse than before they installed LABjs), they're not going to say, "Well, I'll just keep LABjs in there and hope those browsers fix this quickly".

This is tail-wagging-the-dog mentality, and it ignores the reality: people will almost always chose the path of least resistance. If they try a script loader, and it gives them worse performance than before, they'll simply take it out. They may complain about it once in a tweet, but they won't take a stand against the browsers to the detriment of their own site and their own users, and they won't tell all their users to switch to another browser in protest.

And worse, for LABjs, the path of least resistance may very well mean that if performance is important to them, they'll just pick some other loader, which has more hacks in it. As long as they get what they want, which is reliable and pretty good performance, they'll be happy. And it will totally have been lost on them that the battle for web standards was just dealt a blow by their actions. General web page authors do not care to fight that battle on behalf of LABjs. So, LABjs must fight that battle under the covers.

I understand your perspective, but I can say as the maintainer of a tool like LABjs that cares about keeping its relevancy for "survival", I won't take an action that I know is likely to cause a decline in the usefulness of my tool. Instead, I will take a more cautious, slow-to-change approach, while at the same time feature-testing for the new standards and using them if available. Only after a long time of the new feature-testable stuff being present will I consider removing the legacy stuff. This is a strategy I think almost every framework/lib maintainer would echo support for.

~~~~
</blockquote>

[[User:Getify|Getify]] 21:39, 23 December 2010 (UTC)

Talk:Dynamic Script Execution Order

2010-12-23T21:39:16Z

Getify: response about `async`

Please discuss the proposal here. All informal feedback is welcomed, and when it's appropriate, please add content to the main page.

== What about CommonJS / RequireJS? ==

I'm not sure we need to complicate the HTML or browser engines in order to satisfy the advanced use cases. To me it seems that the JavaScript langauge itself could abstract the requirements and let the browser vendors implement whatever solution they see fit. Specifically, if JavaScript provided the define() and require() calls proposed in the CommonJS "specifications" (and implemented by [http://requirejs.org/docs/api.html RequireJS], [http://svn.dojotoolkit.org/src/dojo/trunk/_base/_loader/loader.js dojo (trunk)], and others *Yabble?), then browsers could just load and evaluate scripts as fast as possible without regard to script execution order.

This would solve all of the problems except for the current inability to use loaders like LABjs in FF4 or webkit. To solve that problem, we should consider keeping the existing functionality or triggering the deprecated functionality when needed.

--[[User:Unscriptable|Unscriptable]] 01:29, 2 November 2010 (UTC)

=== Response ===

This is a valid point except that it assumes that all code that needs to be loaded is "modular"... in fact, most code on the internet that needs to be loaded is NOT modular, and instead requires particular ordering when being loaded... for instance, "jquery" and "jquery-ui" -- jQuery must be run before jQuery-UI is loaded and run.

The spirit of this proposal is to add the facility to native browser (rendering engine, specifically) behavior, such that any and all existing content is able to be loaded (even with dependencies and order) without modification.
<blockquote style=background-color:#eee>
Are we trying to codify how one would implement this HTML dynamically so I can achieve parallel loading but retain dependency that is inferred in the order?

<blockquote style="background-color: white">
<script src="jquery.js"> </script> <br/>
<script src="jquery-ui.js"> </script>
</blockquote>

If so, we must consider the case in which the dependency itself loads additional code which the discussions around `async=false` or even text/cache do not account for.
[[User:Serverherder|Serverherder]] 19:23, 15 December 2010 (UTC)
</blockquote>

=== Dependent code should be modular ===

I completely agree, 99% of JavaScript in use today is NOT modular, but that's arguably because there was no built-in support to make it modular (IMHO, YMMV, RTFM, BBQ, ROFL). But that doesn't mean there aren't dependencies that span script files / script nodes. I don't know how many sites would be broken (or if there is any way to determine how many sites would be broken) if/when the latest browsers started loading and evaluating script-injected scripts out of order. It's not just LABjs-based sites. I'll bet many dojo and YUI sites will break, too (although I don't know this for a fact because I don't know exactly how their dynamic script loaders work).

'''''In any case, breaking existing sites is a BAD IDEA. :) There should be some way to allow LABjs and other dynamic script loaders to continue to work.'''''

The part I don't agree with in the proposals is that it should be the job of HTML and/or the browser engine to manage dependencies. Specifically, I am talking about the scriptGroup element and the "waitFor" attribute. The "async" attribute may be the right level: it appropriates only general heuristics to the browser: ''load these scripts whenever you like, but load these other scripts in this order''.

Detailed dependency management belongs in the modules, though. This is how it's done in most environments / languages: import statements, include statements, etc. It's no different in JavaScript, if a developer wants to take advantage of some code in another module, she/he should import it into their current module. This should be the model moving forward. It's not hard, it's not un-web-like, and it's already being done.

Existing code can be made to work modularly, too:

1. Identify modules and wrap them with a define() method.
2. Identify dependencies using either the [http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition Asynchronous Module Definition] format or the CommonJS synchronous format

async format:
<pre lang="javascript">
define(['dependency1', 'dependency2'], function (dependency1, dependency2) {
/* this is the factory function, return the module inside here */
return { /* some object, but could also be a constructor or a function */ };
});
</pre>
sync format:
<pre lang="javascript">
define(function (require, exports, module) {
/* this is the factory function, require dependencies and return the module inside here */
var dependency1 = require('dependency1');
var dependency2 = require('dependency2');
return { /* some object, but could also be a constructor or a function */ };
});
</pre>
In the async case, the browser may employ whatever method it sees fit (e.g. parallel) to download the dependencies since the code inside the factory function won't execute until all of the dependencies are loaded and evaluated. In the sync case, the browser has no choice but to download and evaluate the dependency before continuing code execution. It's conceivable that the browser could find and asynchronously pre-fetch the inline require()'ed dependencies in the sync case. (RequireJS doesn't quite do this. Instead I believe it finds the inline require() calls and converts the module to an async module.)

'''''So, in short: don't break LABjs (or any other script loaders), but don't extend the spec to manage dependency management from HTML.'''''

--[[User:Unscriptable|Unscriptable]] 01:29, 2 November 2010 (UTC)

== Response #2 ==

The cat's already out of the bag... we've got a dozen+ years worth, hundreds of millions of javascript files out there, which are NOT modular, and will not be modified to be modular.

If we're talking about either trying to change all the JS on the web to be modular, or trying to extend the HTML markup spec to include a better facility for accomodating the existing script content, I think the former is idealistic and "correct" but the latter is realistic and "right".

A modular loading system will only work for modular code, but a general loading mechanism in HTML (like the <script> tag) can load both modular and non-modular code, which is why that more general mechanism is what's in HTML right now and not some more specialized loading API that only loads a small percentage of JavaScript code out there.

The <script> tag has worked fine forever, and there's been no real big push to do away with it in favor of having all loading handled by JavaScript -- in fact, that would be impossible because if you had no way to load JS onto the page with a <script> tag, then no JavaScript could run on a page to load more code. So I don't agree that we should stop adding functionality to the HTML loading mechanism and only focus on JavaScript.

If we agree that the <script> tag itself is not only required but normative, then I'm not sure why decorating the <script> tag with additional behavior to help it be more powerful is a bad pattern. We've addded "defer" and "async" already. I'm not sure I understand why adding a wrapper tag called "scriptGroup" would be that much different than attributes on the <script> tag?

I also don't think that "scriptGroup" constitutes "dependency management". "scriptGroup" is a semantic way for a web author to express that they want to group a set of scripts together ONLY so far as execution order behavior is concerned. It implies nothing more to it (that "dependency management" would imply) than that.

For instance, consider this: if JavaScript had been built with non-global context and statement level context and sandboxing and such things, we'd have a much more secure JavaScript right now. But just because JavaScript may someday be taught some new tricks in terms of security, that doesn't mean that "now" HTML shouldn't try to help solve the problem. If for instance the <frag> tag can be used to create a sandboxed environment for third-party JavaScript code to run in, this is a much easier way to address the security problem than to suggest we have to wait for ES-Harmony to add extra syntax to the language to accomplish the same thing.

[[User:Getify|Getify]] 02:13, 2 November 2010 (UTC)

== Text/cache solution ==

It seems to me that having a real text/cache script type, or a similar element that fires a load/error event and provides a .text property gets you where you need to be. You could setAttribute("type", "text/JavaScript") or use the text to create a new script element. Or a new style element, or whatever. That puts you in control of when script or CSS is interpreted. With async as the default, you don't need a new ordered attribute as that's easily managed in script.

== "text/cache" response ==

On the surface, this idea sounds like it's pretty similar to <link rel=prefetch> -- in other words, we've already standardized a way to prefetch a resource into cache, and probably in a better way than the hack that I did in LABjs of just relying on it fetching unrecognizable content.

Unfortunately, it still suffers some similar problems to <link rel=prefetch>.

Firstly, if the notion is that you'd use <script type="text/cache"> to prefetch, and then you'd make a second request for the resource with a real <script type="text/javascript> node, it suffers the faulty assumption that the resource was served with proper cache headers.

If we try to avoid the need for the second request by suggesting that you can access the `text` property of the node (and then eval() or inject that code when you want to execute it), this runs afoul of the same-origin policy problem if you requested the script from a non-local domain.

The part of your suggestion that holds water would be if, given a "prefetched" script node that didn't execute yet, I could simply change that node's `type` value from "text/cache" to "text/javascript", and that would explicitly trigger the browser to immediately execute it.

This is an interesting idea. I can see though that it perhaps has some potential complications.

For instance, would the browser have to keep a "hasExecuted" internal flag, so that changing the `type` value would only at most result in one execution? Also, if the script node in question is loaded but not executed, can the page alter the script code (by setting its `text` property) before making the change to the `type` value? In that case, should the browser execute the original code or the modified code? I can see security implications and confusion abounding in that behavior.

Lastly, as mentioned above, this basically copies (in a similar but not exactly identical way) the <link rel=prefetch> behavior. It may be seen as a negative to be trying to step on the toes of <link rel=prefetch>, and also it may be more confusing to the general public as to why you'd use one technique or the other, given their differences being so nuanced.

That having been said, I can see that it's a viable alternate proposal. It's worth adding a note to that section of the main Wiki page and to getting some feedback from browser vendors on if they feel this is a more realistic/suitable solution to the use-case.
<blockquote style="background-color: #eee">
The difference between pre-fetching and this proposal seems pretty clear: Prefetching, if not performed now, will eventually be done once the user explicitly requests the page. while the "text/cache" solution indicates that the resource should load '''immediately''', not during idle time.

<br/>
[[User:Serverherder|Serverherder]] 19:10, 15 December 2010 (UTC)
</blockquote>

[[User:Getify|Getify]] 20:56, 4 November 2010 (UTC)

== RequireJS order support ==

I am the main developer for RequireJS, and just want to voice my support for a solution that works on the script element itself, either by leveraging the async attribute or allowing something like an "order" boolean attribute that would allow specifying a dynamically added script element should be executed in the order that it appears in the DOM. This capability should be something can be capability detected to avoid browser sniffing.
<blockquote style="background-color:#eee">
Why shouldn't dependency management be implemented in high-level code and the browser simply provide a means by which parallel loading can be achieved? As you know, there is a considerable amount of nuance. I'm of the opinion that implementing dependency management in the engine will eventually lead us right back to where we were 10 years ago with inline script tags which provides an easy method for dependency management at the expense of unmanaged blocking and an inability to detect or adapt to errors. <br/>
[[User:Serverherder|Serverherder]] 19:51, 15 December 2010 (UTC)
</blockquote>

There are many scripts on the web today that have implicit dependencies that should be loaded in a specific order, but the application developer will want to use dynamically created script elements for best performance. jQuery plugins that depend on the jQuery script already been executed in the page are a good example.
<blockquote style="background-color:#eee">
Agreed, but I don't believe the proposals allow for proper emulation of the dependency management provided by script tags. Prototype.js, for example, loads its core modules dynamically (using document.write so maybe not the best example...). When prototype.js is included via script tags, ensuing script blocks are free to "depend" on all of these modules; Dynamically creating a dependency on prototype.js by loading both with the `async=true` property will fail since prototype.js won't be able to "jump the queue" and add insure its core modules load before its extensions. <br/>
[[User:Serverherder|Serverherder]] 19:51, 15 December 2010 (UTC)

<blockquote style="background-color:#ccc">
I have to admit, you raise a valid point with respect to that common usage. The YUI model (where the framework is responsible for all loading) is perhaps the more appropriate model to move toward, though. Or, the framework doesn't auto-load its own dependencies at all. In either case, I think it's cleaner to have one loading mechanism in play rather than two or more competing ones, because as you point out, this is going to get messy. I still am not sure this means that the async=false proposal is lacking, because as I think about how complicated such a split loading would be with your `readyState` proposal, that seems even worse/more complicated to me. [[User:Getify|Getify]] 20:06, 15 December 2010 (UTC)
</blockquote>
<blockquote style="background-color:#eee">

I would not argue '''against''' a global queue for synchronized execution, I just think the usefulness of such a construct declines as scripts that "I don't care about" are added. It's my opinion the spec should provide the ability for high-level code to implement similar constructs, regardless of how complex it may be to do so. <br/>
<br>
That being said, I don't think it's any more complicated than existing models. Here's a demonstration of an [http://digital-fulcrum.com/executionorder/ IE-only parallel-loading, synchronously-executing script queue] implemented in 40 lines of code. It tests both cached and un-cached scripts (from the LABjs test suite) and has been tested and found to be working in IE6-8.
<br>
[[User:Serverherder|Serverherder]] 01:52, 16 December 2010 (UTC)
</blockquote>
</blockquote>

- James Burke

== Vendors Should Implement the Existing Suggestion ==

Since the spec all ready includes a suggestion to download resources when the SRC attribute is set, parallel loading is an option the '''vendor''' chooses to implement and not something a script loader should be able to require. Vendors that don't implement the suggestion will run the risk of being less performant in these situations. That, however, is '''their''' choice to make as the spec suggests. If the benefits of parallel loading dependencies are so great, users will opt for this in their choice of agent or vendors can adopt the existing mechanism.

== The Current Suggestion Should be Changed to a Mandate ==

The spec is pretty clear on why it chose to make this optional. If dependent script loading is so common that browsers that adopt the suggestion enjoy considerably better performance, the user will eventually decide to opt for those implementations. On the other hand, if it is more common that scripts are created and never inserted, leading to wasted bandwidth and clogged fetching queues, the converse will occur. Either way, by making it optional, the spec hedges its bet and is more prone to be future-proof as the habits of script developers evolve.

== Modify the specification so parallel-loading is configurable ==
The specification expresses the reasons parallel loading should not be done. To this point, allowing developers a means to '''require''' resources be downloaded in parallel is in direct opposition to the spec's all ready stated position. To this end, I see no purpose for async=true: A browser that hopes to be highly performant should implement the spec's suggestion to improve performance. Developers should not be able to circumvent the vendor's attempt to be conservative in its use of bandwidth simply to achieve ordered execution.

=== response ===
Nothing about this proposal requires any parallelism that the browser wouldn't already afford. The spirit of this proposal is not about loading behavior, but about execution order.

The spec says nothing about the parallel loading, nor do I think it should necessarily. All modern browsers HAVE in fact implemented parallel loading for all scripts, regardless of async or not. And I think this is a good thing. But it has nothing to do with `async` or my proposal to make the definition of `async` symmetric/consistent between markup script elements and dynamic script elements.

The spec already defines that `async` is specifically to create unblocking of the page's resource loading AND "as soon as possible" execution of the script. But it only defines this for parser-inserted (markup) script tags. I think this is short-sighted, because I think a script-loader should be able to opt into either ordered or unordered execution in the same way that markup script elements can. That's really all the main proposal is about.

[[User:Getify|Getify]] 21:39, 23 December 2010 (UTC)

Dynamic Script Execution Order

2010-12-23T19:32:36Z

Getify: updating comments around the "preloading" technique IE (and the spec) give

This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.

Briefly, this issue has arisen because recent "nightlies" changes in both Mozilla Gecko and Webkit have broken the ability for script-loaders like [http://labjs.com LABjs] to be able to download scripts in parallel but ensure their execution order. As a result of the discussion, it's become apparent that both the spec for, and various current browser implementations around, dynamic script loading is incomplete in addressing this use case, and that some change needs to occur.

There is one main proposal that has surfaced from the discussions, with several other alternatives having been discussed. This page will try to distill the long email thread down and clearly present the main proposal, objections, and alternative suggestions.

Please feel free to join the discussion of this topic in the [[Talk:Dynamic_Script_Execution_Order]] area.

== Use Case Description ==
Script tags/elements can either:

a) appear in the HTML markup ("parser-inserted"), OR

b) be dynamically appended to the DOM using document.createElement() ("script-inserted")

Parser-inserted script tags, up until recent browser versions, had the undesirable performance behavior of loading and executing serially, blocking everything else while doing so. Recently, many browsers have improved the situation by loading the scripts in parallel, but still executing them in order.

On-demand (or dynamic) script loading has emerged in recent years for a variety of different reasons, most notably the performance improvements to address such concerns. It is desired by many different scenarios to be able to download scripts to a page completely independently of the loading of the rest of a page's resources, or even well after a page has finished loading ("on-demand").

Recent additions to HTML spec such as "defer" and "async" were intended to address the use-case for parser-inserted script elements, but their behaviors have been unhelpful for the on-demand loading use-case (script-inserted script elements).

Thus, script loaders (like [http://labjs.com LABjs]) were developed to give page authors an easy way to specify one or more scripts to load (regardless of when in the life-time of the page that loading is requested), and for as many of them as possible to load in parallel, and for those scripts to be loadable from any local or remote domain location, and for the script loader to be able to control the execution order (if the usage of the script loader's API expresses the need to) to preserve dependencies between the scripts.

Sometimes, dynamic script loading is used to load totally independent scripts, and thus "as fast as possible" execution is desired. Other times (and possibly more frequently), multiple scripts are loaded with some dependencies among them, requiring them to execute in a certain order.

What is needed is some facility by which a script loader can express that dynamic script loading either does or does not need execution order preserved among the queue of requested script loadings.

=== Current Limitations ===
Unfortunately, browser behavior around script-inserted script elements and their loading and execution behavior is splintered. There are, at present, two main camps of behavior:

a) in IE and Webkit (including Chrome), the default behavior for script-inserted script elements is for them all to execute in "as fast as possible" mode, meaning there's no guarantee about ordering. This effectively makes on-demand (dynamic) script loading impossible to work in parallel-mode if the resources in question have dependencies -- the only straight-forward way to handle things is to load each file and execute, serially, losing the parallel loading performance benefits.
<blockquote style="background-color: #EEEEEE">
I'm not sure if this is the case.

IE will start fetching resources without execution simply by setting the src attribute. Scripts will not execute, however, until they are added to the document. Since IE supports the readyState attribute and readystatechange event, it's possible to load scripts in parallel and execute them in order without resorting to invalid type attribute hack-ery.

<pre style="background-color:white" lang="javascript">
script= document.createElement("SCRIPT");
script.onreadystatechange= function(){
if(this.readyState == 'loaded')
/*
Network fetch is now complete, following
triggers synchronous execution.
*/
document.body.appendChild(this);
else if(this.readyState == "complete")
this.onreadystatechange= null;
}
script.src= "foo.js";
/* Network fetching begins now */
</pre>
</blockquote>

<blockquote style="background-color: #ccc">
I've experimented with such things heavily in the past, and I'm fairly suspicious that this is not reliable across various versions of IE (6-9), nor does it work reliably the same depending on if an element is already in the browser cache or not. I'm not 100% certain that what you suggest is flawed, but I have a strong hunch that it can be shown to have some holes in it for IE loading. I will try to create some test cases to prove or disprove.
<blockquote style="background-color: #EEEEEE">
When loading a script that is in the cache, IE requires the event handler be installed prior to setting the `src` attribute. Otherwise the element's transition to the "loaded" state will be missed. IE routinely "skips" ready state transitions when cached scripts are immediately inserted into the DOM so suspicion is understandable; however, delayed insertion works around this "problem". The script above has been tested in IE6-8 with scripts in a variety of caching states and found to work correctly.
</blockquote>

Moreover, you're suggesting something that is AFAIK only IE right now, <del>and definitely appears to not be standardized. In the same way that I'm hesitant to continue pinning loading behavior on hacks like the invalid type attribute value, I wouldn't want to approach loading with this technique (even if it were proven reliable on all IE's under all caching circumstances) unless it was a serious proposal to the W3C to have this technique be the new standard (as opposed to the current proposal, as implemented by Mozilla and Webkit now).</del>

Update: the behavior *is* in fact in the spec as a suggestion (aka, with "may" instead of "should"). The wording in question is located in [http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML5 4.3.1, "Running A Script" algorithm] step, 12, which states:

<blockquote style="background-color:#f1dac9">
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

[[User:Getify|Getify]] 19:32, 23 December 2010 (UTC)

<blockquote style="background-color: #EEEEEE">
I think you're right: Only IE impelements this event and property on script elements. The readystatechange event, however, is widely understood due to the XmlHttpRequest implementation and `readyState` property has been added to the `document` in WebKit, Mozilla and IE.
</blockquote>

That having been said, I think this is at least a viable candidate for "Alternate Proposals" and deserves to be [[Dynamic_Script_Execution_Order#readyState_.22preloading.22|listed as such]]. As always, I welcome input from the community on all the ideas presented here, including this one. But, since the main proposal (async=false) is already being implemented by at least two major browsers, I'm not sure if the tide will be changed or not.

</blockquote>

<blockquote style="background-color:#ddd;">
Also, the suggestion of handling the "preload" and deferred execution via the script tag's `readyState` property is very similar in spirit to the suggestion that was made to explicitly support [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|preloading into cache without execution]]. As I said, either of those two approaches might work, but they both put more of the onus of complexity in managing multiple dependencies on the high-level code (author, script loader, etc). I'm more in favor of this functionality being explicitly built-in natively into the queues. As always, I welcome comments to any side of this discussion.

[[User:Getify|Getify]] 18:35, 15 December 2010 (UTC)
</blockquote>

b) in Gecko and Opera, the default behavior for script-inserted script elements is for them all to load in parallel, but execute serially in insertion order. Technically, this makes it impossible to dynamically load independent script elements and have them execute in "as fast as possible" mode.

As described above, both behaviors are desirable under different circumstances, but each of the two camps provides only one behavior, and no way to straightforwardly achieve the other. This obviously creates a big nightmare interoperability-wise when trying to provide a general script loader cross-browser.

Since it is observed that the behavior in (a) is more detrimental (race-condition wise) for the case where dependencies exist, script loaders like LABjs had to find some way around this problem while still attempting the best possible parallel loading performance. However, the trick used is hacky and not completely reliable -- yet it is the best way to solve the use-case in <s>IE and </s>Webkit.

For Gecko/Opera, the concession was just (silently) made that the lesser-common use case of "as fast as possible" wasn't possible, but degraded fine to "insertion order execution", while keeping the parallel loading benefits.

<blockquote style="background-color: #EEEEEE">
Gecko's strict execution order creates dependencies between scripts which are unrelated and prevents the ability mitigate the impact of server outages / network latency. This is exacerbated by the fact that Gecko, unlike IE and WebKit, provides no mechanism to <b>remove</b> scripts from the execution queue.

Consider the case where JSONP is used to provide auto-completion. The user types "hello" and the JSONP request is made; however, the "currently" loading script is out-of-date as soon as the user modifies his search to "hello world". Gecko's algorithm requires the out-of-date request load and execute before the second request.
</blockquote>

Recently, Gecko landed a [http://hg.mozilla.org/mozilla-central/rev/a60414d076b5 patch] to the trunk that stopped Gecko's existing behavior of preserving execution order, making script-inserted script elements now execute in "as fast as possible" mode similiar to IE/Webkit. Unfortunately, the "workaround" used in IE/Webkit (described in the next section) for dealing with parallel loading and execution-order dependencies does not work in Gecko, which means presently the use-case in question is now broken in Gecko trunk/FF4 nightlies.

Moreover, Webkit recently landed a [http://trac.webkit.org/changeset/67245 patch] to the trunk that stopped Webkit's non-standard but long-held behavior (also used in the "workaround" described in the next section) of loading into cache script resources with an unrecognized "type" value, but silently not executing them. This behvaior (while hacky) is central to being able to address the use-case in question in Webkit, so at present, Webkit nightlies are now also entirely broken on the use-case (though in a different way than Gecko).

Both the Gecko change and the Webkit change are well-intentioned, as they are bringing the respective browser more in line with the HTML spec. However, what's really been demonstrated is that the HTML spec is not properly handling this use-case, and so the goal is not to address the browser issues raised with more awkward hacks, but to address the shortcomings of the spec first, and then encourage all browsers to adhere to such.

<blockquote style="background-color: #EEEEEE">
Considering Internet Explorer's readyState implementation provides a means of both parallel loading and preserving execution order can be achieved, perhaps its "readyState" property and onreadystatechange event should be included.
</blockquote>

=== Current Usage and Workarounds ===
To work around the limitation in IE/Webkit(prior to the above noted patch) of not being able to rely on script order execution for parallel loaded scripts, a "preloading" trick was developed. This trick relied on non-standard (but long-held) behavior in these browsers that a script-inserted script element with an unrecognized "type" value (such as "script/cache") would be fetched/loaded, but would not execute. This had the effect of loading the resource into cache, and then firing the "load" handlers to let the page know when the resource was completely in cache.

Assuming that the resource was served with proper caching headers, and was in fact in the cache, it could then be executed (nearly) immediately when it was the proper execution order time by re-requesting the same resource via another script-inserted script element with the proper "text/javascript" type value, pulling the resource from the cache and executing it, without another server round-trip.

Of course, the assumption of proper cache headers is a huge one, and not at all reliable. Some recent estimates by performance optimization specialists have suggested as much as 70% of scripts across the internet are not served with proper caching headers, which means that such scripts would be completely ineffective if loaded using this (or a similar) technique. The script resource would end up being loaded completely a second-time, and the "near immediate" execution would obviously be false, and thus race conditions would ensue.

It's important to note at this point that the new <link rel=prefetch> facility has been suggested as a better workaround, but it suffers the same ill-fated assumption of script cacheability. Still others have suggested "new Image().src=..." or the [http://www.phpied.com/preload-then-execute/ <object> preloading trick] suggested by Stoyan Stefanov. Again, these tricks unwisely assume cacheability, for the "preloading" trick to solve the use-case in question.

=== At Risk ===
Currently, there are several large/popular web sites which are either currently (or who intend to soon) use LABjs in such a way as to run afoul of the new Gecko and Webkit behavioral changes with LABjs failing to operate properly. It's important to note that the problems of race conditions can be subtle and hard to detect, and so merely loading up such sites and failing to observe overt failure is not sufficient.

Sites which are known to have LABjs loading techniques in place with currently broken (or susceptible to such breakage in the near future) behavior are:

* [http://twitter.com Twitter]
* [http://zappos.com Zappos]
* [http://vimeo.com Vimeo]
* [http://mefeedia.com MeFeedia]
* [http://blog.getify.com Getify Solutions blog (my blog)]
* [http://flensed.com flensed Flash+JavaScript browser shims (cross-domain Ajax, cross-browser cookies, etc)]

Rather than getting hung up in the syntax of usage in LABjs that is or is not going to break, it's best to just think of the problem this way:

Does a site need to load more than one script, at least one of which comes from a remote domain location (like a CDN), and for which among the scripts there's at least one execution-order dependency among them? If so, then that site is susceptible to the current/future breakage if the HTML spec (and browsers) do not address this use case.

A common example (in use on many sites) of such might be loading:

* jQuery from the CDN
* jQuery-UI from the CDN
* plugins and usage code in one or more local files
* Google Analytics from the Google domain

Note that the emergence of popular script frameworks and their hosting on public CDN's is leading to more and more sites loading scripts from both local and remote locations, and also to loading more files that have dependencies (rather than the practice of concat'ing all files into one file to avoid dependency issues).

Any site which fits a profile like the above, and which might currently (many do), or in the future want to, use a script loader to improve their loading performance, will fail to achieve what they want cross-browser and in a performant way, if the HTML spec (and browsers) do not address the use case.

=== Benefits ===
The benefits of addressing both behaviors directly (without "preloading" tricks and bad assumption reliance) have been implied in the above discussion, but in short are:

a) clear and simplified code for script loaders, which leads to easier use by authors of more pages, which in turn leads to better web performance (as demonstrated clearly by intelligent script loading techniques as compared to just simple <script> tags in HTML markup)

b) full access to either/both of the execution-order behaviors (as the author sees fit), regardless of browser

c) avoiding reliance on bad assumptions (like cacheability) as a sufficient way to address the use-case

=== External Discussions of this Feature ===

* <cite>[http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html W3C public-html email thread]</cite>

* <cite>[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 W3C Bug #11295]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=620852 Mozilla Bug #620852]</cite>

* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>

* <cite>[http://hsivonen.iki.fi/script-execution/ HTML5 Script Execution Changes in Firefox 4 Beta 7]</cite>

* <cite>[http://blog.getify.com/2010/10/labjs-w3c-brief-update/ LABjs and W3C... brief update]</cite>

* <cite>[http://blog.getify.com/2010/10/ff4-script-loaders-and-order-preservation/ FF4, script loaders, and order preservation]</cite>

== Proposed Solutions ==

=== My Solution ===
The current proposal most well supported from the email discussion thread, and the one which I feel makes most sense, is described here.

The HTML spec already defines the "async" attribute for parser-inserted script tags, which when set to "true", changes their execution order behavior to be like script-inserted script-elements (in IE/Webkit), which is that they load in parallel and execute "as fast as possible" (ostensibly because the author is expressing no dependencies between multiple such "async"-marked scripts). Parser-inserted script elements without "async" (or with it set to false) behave as before and expected, which is that they load in parallel but execute in order.

However, the HTML spec does not define the "async" property (or any such behavior) for script-inserted script nodes (such as those created by a script loader). Instead, the spec implies that "async=true" like behavior is always true for such script-inserted script elements.

What is proposed is:

a) Script-inserted script elements should have (and respect the value of) an "async" property which is basically identical to the "async" attribute for parser-inserted script elements. That is, script elements with the "async" property set to "true" will behave accordingly, as will script elements with the "async" property set to false.

Essentially, the proposal is to mirror the "async" attribute behavior of parser-inserted script elements as an "async" property on script-inserted script elements. This has the benefit of using an existing facility and extending it (from current spec) in a way that is sensisble and symmetric with its current definition.
<blockquote style="background-color: #EFEFEF">
The scriptgroup or `readyState` alternate proposals allow for dependency management to be done in high-level code. The singular syncrhonized execution queue proposed here introduces artificial dependencies, undermining some of the benefits dynamic script loading provides.
</blockquote>

<blockquote style="background-color: #ccc;">
It's important to note that `async=false` scripts will load in a separate queue from `async=true` scripts. It's not that all scripts will now be forced into this insertion-order-execution queue. An author (or script loader) can chose which queue to put a script loading into based on the needs of the page and the resource. If I have a few scripts that are unrelated to each other and the main page (like Google Analytics, social sharing buttons, etc), I'll load those via `async=true`. For other scripts, where order matters for dependency sake, I'll use `async=false`. I think having both those queues available to high-level code is enough control over loading to serve the majority of use-cases pretty well.
<blockquote style="background-color: #EFEFEF">
If at any point these services begin dynamically loading `async=false` scripts of their own, they will begin blocking. This can lead to unexpected behavior of existing code as third-party libraries and services change. It would seem the specification should provide a means by which this blocking can be isolated to dependencies defined by the author and ordered execution not introduce conditions that allow unrelated libraries to affect this.
</blockquote>
</blockquote>

b) Furthermore, to aid in "feature-detection" of such new behavior, the proposal is to have the default value for the "async" property of script-inserted script elements be "true" (and of course the associated behavior thereof).

There are two major benefits to (b). One is that it provides a way to feature test such new behavior by not just looking for the existence of the "async" property on script elements, but specifically that the default value is "true" (which is opposite of what it would currently/normally be). Secondly, defaulting to "async=true" behavior for script-inserted script elements would preserve the default behavior of IE and Webkit, meaning there'd be less of a chance of breaking existing web content in either of those two browsers.

It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.

==== Proposal Amendment: Need Attribute/Property Semantic Inconsistency ====
In order to achieve consistency between the semantics of how the parser-inserted script element's `async` attribute and the script-inserted script element's `async` property behave, a slight change needs to be made to the value parsing/interpretation for parser-inserted script elements' `async` attribute.

If a parser-inserted script element has the `async` attribute present, but its value is exactly "false" (or any capitalization thereof), the script element should behave EXACTLY as if no `async` attribute were present.

If the attribute is present and either has no value, or has any other value except "false" (for instance, "true" or "async"), then it should be interpreted to be turning on "async" for that element.

Because it is highly unlikely (and indeed, quite irrational) that any existing web content is doing `async="false"` in HTML markup and yet still expecting "async" behavior to be turned on, it is pretty unlikely that this minor interpretation change will cause backwards-compatibility issues.
[[User:Getify|Getify]] 03:05, 22 December 2010 (UTC)

==== Proposal Amendment: Events ====
In addition to standardizing how scripts load and execute, it's also important to standardize the load and error events, and under what circumstances they fire, etc. Without reliable load/error events, the main proposal is not reliable and is thus unhelpful for the use-case.

A script-inserted script element must fire the "load" event only once, when:

a) immediately after the resource finishes loading, but before parsing/execution, AND

b) the script element loads any non-empty content (that is, it was a successful HTTP request), AND

c) the script element has either loaded from the remote location, or is loaded from the brower cache

Specifically, the script "load" event must come immediately between the script element finishing loading and the script element being parsed/executed. If the script resource successfully loads, nothing should interrupt the sequence of fininshing loading, the "load" event firing, and the script being parsed/executed.

A script-inserted script element must fire the "error" event only once, when:

a) immediately after a loading failure for the resource is detected (that is, an HTTP error received, such as 404, 500, 503, etc).

Either the "load" or "error" event, but not both, will fire, and only once, for every script-inserted script element.

NOTE: "load" and "error" events on script-inserted script elements must fire synchronously to ensure event reliability.

A case may be made for adding the "load" and "error" events as described here to parser-inserted script elements as well.

==== Processing Model ====
Script inserted script elements will have an "async" property that defaults to "true". If the author does not change the value, all such requested script loadings will be in their own "queue" and will default to "as fast as possible" execution behavior. For any script elements that the author sets "async=false", those scripts will load in a separate "queue", and will execute in insertion order only. Again, these two "queues" will operate strictly independent of each other.

==== Processing Model Details (without the event amendment) ====

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node.

When a previously-created script element node loses its parser-insertedness, if the element doesn't have the async content attribute, set the force-async flag to true and false otherwise.

When a script element node obtains the async content attribute (via setAttribute, setAttributeNode, setAttributeNS, by the fragment parser or the XSLTProcessor adding the attribute, etc.), set the force-async flag to false. (Note that calling removeAttribute("async") doesn't modify the force-async flag.)

The async IDL attribute must behave as follows:
* Upon setting, set the force-async flag to false and then reflect the async content attribute.
* Upon getting, if the force-async flag is true, return true. Otherwise, reflect the async content attribute.

In step 13. of http://www.whatwg.org/specs/web-apps/current-work/#running-a-script before the case "If the element has a src attribute" add a case:
If the script has a src attribute and the async IDL property getter returns false,
The element must be added to the queue of ordered script-inserted external scripts of the Document of the script element at the time the running a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run these steps:
# If the queue of ordered script-inserted external scripts is empty or the first script in the queue of ordered script-inserted external scripts has not been fetched yet, abort these steps.
# Execute the first script in the queue of ordered script-inserted external scripts.
# Remove the first script from queue of ordered script-inserted external scripts.
# Goto step #1.

Modify step 5 of http://www.whatwg.org/specs/web-apps/current-work/#the-end to say:
Spin the event loop until the set of scripts that will execute as soon as possible is empty and the queue of ordered script-inserted external scripts is empty.

==== Limitations ====
The two behaviors being identified solve either the case where no dependencies exist, or where a linear dependency chain exists (and which the script elements can be requested to execute in that order). It is possible that some authors have a more complex non-linear dependency chain that they would like to express. This would obviously require a much more complex API and spec change, and since that use-case has not (yet) surfaced as a particularly main-stream request, I believe it would be overengineering to try to address it with this proposed change set.

In addition, it's been duly noted that it's undesirable (and potentially confusing/problematic) to intentionally build in the inconsistency of having the "async" attribute (for parser-inserted scripts) and the "async" property (for script-inserted scripts) have different default values ("false" for the attribute, "true" for the property).

It's also been a point of discussion whether or not such a spec change has enough "carrot" to entice the browser vendors (namely IE and Webkit) to implement the behavior. Moreover, there's been some concern that if the default value for the "async" property were made to be "false" (like the attribute) to be more consistent and conservative, then it would possibly give the perception to IE and Webkit of "losing" some performance to cut out their default "as fast as possible" behavior.

=== Alternate Proposals ===
One early proposal on the email list was to introduce an entirely new property like "ordered" which an author could add to a script-inserted script element to instruct the browser to put it into the queue of execution-order-preserving script loadings. While such a property would address the use case, it introduces another property and thus more complicates the issue. It also fails to address the current spec inconsistency (which is confusing to new comers) that "async" is not a present/respected property in mirror of the attribute of the same name.

Another suggestion was a "waitFor" property that would be added to script elements and would specify a list of one or more DOM id's of other script elements that the current script should "wait for" in terms of execution. Again, this would solve the use case, but in a more complicated way, and there are concerns that it would be too confusing for the normal use-case.

Several suggestions have come in the form of creating explicit "preloading" (similar to <link rel=prefetch>), but as described above, "preloading" to solve this use case is a non-ideal hack and highly susceptible to breakage if the script fails to be sent with proper caching headers.

It's also been suggested that since this type of behavior is somewhat complicated, it may be better to intentionally obfuscate or complicate any such facility in the HTML, so as to make the barrier-to-entry rather high and force users to know what they are doing before doing it.

It's been suggested that "defer" already preserves execution order. However, "defer" is only defined for parser-inserted scripts, and thus is not applicable to the use-case in question from an on-demand point of view. Also, "defer" scripts explicitly way for DOMContentLoaded, even if they're ready to execute sooner. So this is less than desired.

Yet another proposal is a "document.executeScripts()" API, where an author can specify multiple sets of scripts that can load in parallel and it will enforce their execution order. A variation on that same idea was to use the "importScripts" from the Web Workers spec, however "importScripts" is synchronous (undesirable performance wise, obviously). The main downside (besides extra API complication) to "document.executeScripts()" is that there seem to be quite a few script execution properties/behaviors (including "document.currentScript" and charset override) which would have to be duplicated into this API facility.

==== "Script Group" element ====
One recent alternate proposal bears some special consideration, as it seems like it might be a decent option (although certainly more of a radical change for the spec and for browsers to implement). But it has the appearance of being pretty straightforward and semantic for authors to use, perhaps even more so than using "async".

The proposal is to create a new HTML element, called perhaps <scriptGroup>, <collection>, etc. Specifically, this element must be able to be inserted wherever a <script> element can currently be inserted. The "script group" element is intended to signify that all script elements added to it must perserve insertion execution order. This element wouldn't have much (but still some, explained in a moment) meaning in a parser-inserted context, since parser-inserted scripts already preserve order among themselves.

An advantage of the "script group" element would be to give a direct and easy way to attach event listeners ("load" and "error") to the entire group, rather than having to internally track events for each element if all you care about is the final "load" event, for instance. In the case of event handling, the "script group" element would have perhaps some benefit even in parser-inserted (markup) context.

The element would need to have an "id" property, and possibly attributes for "load" and "error" events.

A variation on how to look at this proposal is that a "script group" element could have an attribute/property on it (perhaps called "ordered") which would allow the group to either be order preserved or not. This would make the "script group" element much more useful in the parser-inserted context, as it would sort of be a shortcut to setting "async=true" on all the child script elements.

The "script group" element might look like this:

<scriptGroup id="group1">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

Or, with the "ordered" attribute to explicitly control ordering behavior for the group:

<scriptGroup id="group1" ordered="true">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

<scriptGroup id="group2" ordered="false" onload="alldone();">
<script src="baz.js"></script>
<script src="far.js"></script>
<script src="zab.js"></script>
</scriptGroup>

While the "script group" element is definitely more complicated to define and implement, it does have some semantic advantages for authors, and it also would significantly reduce the internal complexity of script loaders like LABjs. It would give authors (either directly or through script loaders) the flexibility to group scripts together into one of the two aforementioned behaviors (execution "as fast as possible" or "in insertion order"), and to easily access both behaviors in the same page.

==== Explicit support for "text/cache" MIME type behavior ====
Yet another alternate proposal has been suggested in the [[Talk:Dynamic_Script_Execution_Order]] thread.

Essentially, the proposal is that <script> tags directly support being declared with a `type` value of "text/cache". The behavior would be that the script resource is fetched, as the load events fired, as normal, but that the script itself would not be executed. Then later, at the desired time, the script in that element could be executed by changing the `type` value from "text/cache" to "text/javascript".

The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.
<blockquote style="background-color:#eee">
And does the onload event fire again after the script executes? <br/>
Or only when it's loaded? <br/>
Both seem to violate current `onload` semantics.
[[User:Serverherder|Serverherder]] 20:27, 15 December 2010 (UTC)

<blockquote style="background-color:#ccc">
As far as I'm concerned, I think the "load" event should happen immediately after a script loads, but before it executes, as I spell out in the [[Dynamic_Script_Execution_Order#Proposal_Amendment:_Events|Events proposal ammendment section]]. [[User:Getify|Getify]] 20:33, 15 December 2010 (UTC)
</blockquote>

</blockquote>

==== readyState "preloading" ====
Per the suggestion/comment added to the above [[Dynamic_Script_Execution_Order#Current_Limitations|Current Limitations]] section, it's been suggested that IE's current behavior with respect to the `readyState` property can adequately serve the use-case in question. This alternate proposal is very similar in spirit to the [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|previous section on explicit support for "text/cache"]] mime-type value.

The idea is that IE will begin fetching into the cache a script resource as soon as the `src` attribute of the dynamic script element is set. But IE will not execute the script (even if it finishes loading) until the script element is added to the DOM. However, the `readyState` property of the element, combined with the `onreadystatechange` handler listening for changes, can detect when the script has finished loading, by receiving the "loaded" value.

In this way, a script loader could "preload" a set of scripts all in parallel, but control their execution order by delaying the appending of the element to the DOM until execution is desired.

'''Update''' [[User:Getify|Getify]] 14:10, 20 December 2010 (UTC)

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

This seems to be the spec stating that browsers may do what IE's behavior on scripts does, which is to start fetching the resource once the `src` property is set, but not execute it until the script element is inserted into the DOM.

It would seem then that browsers could/should be petitioned to consider implementing this suggestion, perhaps taking the `readyState` implementation from IE as guidance. While I'm still not sure that this would be my preferred method of solving the overall use-case in discussion on this page, it would be an option for such, and it would also help other use-cases, such as those being discussed in this W3C public-html thread:

[http://lists.w3.org/Archives/Public/public-html/2010Dec/0174.html Need to: "preload" CSS and JS]

[[Category:Feature Request|Dynamic Script Execution Order]]

Dynamic Script Execution Order

2010-12-22T03:07:10Z

Getify: adding link to mozilla bug about attribute/property consistency

This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.

Briefly, this issue has arisen because recent "nightlies" changes in both Mozilla Gecko and Webkit have broken the ability for script-loaders like [http://labjs.com LABjs] to be able to download scripts in parallel but ensure their execution order. As a result of the discussion, it's become apparent that both the spec for, and various current browser implementations around, dynamic script loading is incomplete in addressing this use case, and that some change needs to occur.

There is one main proposal that has surfaced from the discussions, with several other alternatives having been discussed. This page will try to distill the long email thread down and clearly present the main proposal, objections, and alternative suggestions.

Please feel free to join the discussion of this topic in the [[Talk:Dynamic_Script_Execution_Order]] area.

== Use Case Description ==
Script tags/elements can either:

a) appear in the HTML markup ("parser-inserted"), OR

b) be dynamically appended to the DOM using document.createElement() ("script-inserted")

Parser-inserted script tags, up until recent browser versions, had the undesirable performance behavior of loading and executing serially, blocking everything else while doing so. Recently, many browsers have improved the situation by loading the scripts in parallel, but still executing them in order.

On-demand (or dynamic) script loading has emerged in recent years for a variety of different reasons, most notably the performance improvements to address such concerns. It is desired by many different scenarios to be able to download scripts to a page completely independently of the loading of the rest of a page's resources, or even well after a page has finished loading ("on-demand").

Recent additions to HTML spec such as "defer" and "async" were intended to address the use-case for parser-inserted script elements, but their behaviors have been unhelpful for the on-demand loading use-case (script-inserted script elements).

Thus, script loaders (like [http://labjs.com LABjs]) were developed to give page authors an easy way to specify one or more scripts to load (regardless of when in the life-time of the page that loading is requested), and for as many of them as possible to load in parallel, and for those scripts to be loadable from any local or remote domain location, and for the script loader to be able to control the execution order (if the usage of the script loader's API expresses the need to) to preserve dependencies between the scripts.

Sometimes, dynamic script loading is used to load totally independent scripts, and thus "as fast as possible" execution is desired. Other times (and possibly more frequently), multiple scripts are loaded with some dependencies among them, requiring them to execute in a certain order.

What is needed is some facility by which a script loader can express that dynamic script loading either does or does not need execution order preserved among the queue of requested script loadings.

=== Current Limitations ===
Unfortunately, browser behavior around script-inserted script elements and their loading and execution behavior is splintered. There are, at present, two main camps of behavior:

a) in IE and Webkit (including Chrome), the default behavior for script-inserted script elements is for them all to execute in "as fast as possible" mode, meaning there's no guarantee about ordering. This effectively makes on-demand (dynamic) script loading impossible to work in parallel-mode if the resources in question have dependencies -- the only straight-forward way to handle things is to load each file and execute, serially, losing the parallel loading performance benefits.
<blockquote style="background-color: #EEEEEE">
I'm not sure if this is the case.

IE will start fetching resources without execution simply by setting the src attribute. Scripts will not execute, however, until they are added to the document. Since IE supports the readyState attribute and readystatechange event, it's possible to load scripts in parallel and execute them in order without resorting to invalid type attribute hack-ery.

<pre style="background-color:white" lang="javascript">
script= document.createElement("SCRIPT");
script.onreadystatechange= function(){
if(this.readyState == 'loaded')
/*
Network fetch is now complete, following
triggers synchronous execution.
*/
document.body.appendChild(this);
else if(this.readyState == "complete")
this.onreadystatechange= null;
}
script.src= "foo.js";
/* Network fetching begins now */
</pre>
</blockquote>

<blockquote style="background-color: #ccc">
I've experimented with such things heavily in the past, and I'm fairly suspicious that this is not reliable across various versions of IE (6-9), nor does it work reliably the same depending on if an element is already in the browser cache or not. I'm not 100% certain that what you suggest is flawed, but I have a strong hunch that it can be shown to have some holes in it for IE loading. I will try to create some test cases to prove or disprove.
<blockquote style="background-color: #EEEEEE">
When loading a script that is in the cache, IE requires the event handler be installed prior to setting the `src` attribute. Otherwise the element's transition to the "loaded" state will be missed. IE routinely "skips" ready state transitions when cached scripts are immediately inserted into the DOM so suspicion is understandable; however, delayed insertion works around this "problem". The script above has been tested in IE6-8 with scripts in a variety of caching states and found to work correctly.
</blockquote>

Moreover, you're suggesting something that is AFAIK only IE right now, and definitely appears to not be standardized. In the same way that I'm hesitant to continue pinning loading behavior on hacks like the invalid type attribute value, I wouldn't want to approach loading with this technique (even if it were proven reliable on all IE's under all caching circumstances) unless it was a serious proposal to the W3C to have this technique be the new standard (as opposed to the current proposal, as implemented by Mozilla and Webkit now).
<blockquote style="background-color: #EEEEEE">
I think you're right: Only IE impelements this event and property on script elements. The readystatechange event, however, is widely understood due to the XmlHttpRequest implementation and `readyState` property has been added to the `document` in WebKit, Mozilla and IE.
</blockquote>

That having been said, I think this is at least a viable candidate for "Alternate Proposals" and deserves to be listed as such. As always, I welcome input from the community on all the ideas presented here, including this one. But, since the main proposal (async=false) is already being implemented by at least two major browsers, I'm not sure if the tide will be changed or not.

</blockquote>

<blockquote style="background-color:#ddd;">
Also, the suggestion of handling the "preload" and deferred execution via the script tag's `readyState` property is very similar in spirit to the suggestion that was made to explicitly support [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|preloading into cache without execution]]. As I said, either of those two approaches might work, but they both put more of the onus of complexity in managing multiple dependencies on the high-level code (author, script loader, etc). I'm more in favor of this functionality being explicitly built-in natively into the queues. As always, I welcome comments to any side of this discussion.

[[User:Getify|Getify]] 18:35, 15 December 2010 (UTC)
</blockquote>

b) in Gecko and Opera, the default behavior for script-inserted script elements is for them all to load in parallel, but execute serially in insertion order. Technically, this makes it impossible to dynamically load independent script elements and have them execute in "as fast as possible" mode.

As described above, both behaviors are desirable under different circumstances, but each of the two camps provides only one behavior, and no way to straightforwardly achieve the other. This obviously creates a big nightmare interoperability-wise when trying to provide a general script loader cross-browser.

Since it is observed that the behavior in (a) is more detrimental (race-condition wise) for the case where dependencies exist, script loaders like LABjs had to find some way around this problem while still attempting the best possible parallel loading performance. However, the trick used is hacky and not completely reliable -- yet it is the best way to solve the use-case in <s>IE and </s>Webkit.

For Gecko/Opera, the concession was just (silently) made that the lesser-common use case of "as fast as possible" wasn't possible, but degraded fine to "insertion order execution", while keeping the parallel loading benefits.

<blockquote style="background-color: #EEEEEE">
Gecko's strict execution order creates dependencies between scripts which are unrelated and prevents the ability mitigate the impact of server outages / network latency. This is exacerbated by the fact that Gecko, unlike IE and WebKit, provides no mechanism to <b>remove</b> scripts from the execution queue.

Consider the case where JSONP is used to provide auto-completion. The user types "hello" and the JSONP request is made; however, the "currently" loading script is out-of-date as soon as the user modifies his search to "hello world". Gecko's algorithm requires the out-of-date request load and execute before the second request.
</blockquote>

Recently, Gecko landed a [http://hg.mozilla.org/mozilla-central/rev/a60414d076b5 patch] to the trunk that stopped Gecko's existing behavior of preserving execution order, making script-inserted script elements now execute in "as fast as possible" mode similiar to IE/Webkit. Unfortunately, the "workaround" used in IE/Webkit (described in the next section) for dealing with parallel loading and execution-order dependencies does not work in Gecko, which means presently the use-case in question is now broken in Gecko trunk/FF4 nightlies.

Moreover, Webkit recently landed a [http://trac.webkit.org/changeset/67245 patch] to the trunk that stopped Webkit's non-standard but long-held behavior (also used in the "workaround" described in the next section) of loading into cache script resources with an unrecognized "type" value, but silently not executing them. This behvaior (while hacky) is central to being able to address the use-case in question in Webkit, so at present, Webkit nightlies are now also entirely broken on the use-case (though in a different way than Gecko).

Both the Gecko change and the Webkit change are well-intentioned, as they are bringing the respective browser more in line with the HTML spec. However, what's really been demonstrated is that the HTML spec is not properly handling this use-case, and so the goal is not to address the browser issues raised with more awkward hacks, but to address the shortcomings of the spec first, and then encourage all browsers to adhere to such.

<blockquote style="background-color: #EEEEEE">
Considering Internet Explorer's readyState implementation provides a means of both parallel loading and preserving execution order can be achieved, perhaps its "readyState" property and onreadystatechange event should be included.
</blockquote>

=== Current Usage and Workarounds ===
To work around the limitation in IE/Webkit(prior to the above noted patch) of not being able to rely on script order execution for parallel loaded scripts, a "preloading" trick was developed. This trick relied on non-standard (but long-held) behavior in these browsers that a script-inserted script element with an unrecognized "type" value (such as "script/cache") would be fetched/loaded, but would not execute. This had the effect of loading the resource into cache, and then firing the "load" handlers to let the page know when the resource was completely in cache.

Assuming that the resource was served with proper caching headers, and was in fact in the cache, it could then be executed (nearly) immediately when it was the proper execution order time by re-requesting the same resource via another script-inserted script element with the proper "text/javascript" type value, pulling the resource from the cache and executing it, without another server round-trip.

Of course, the assumption of proper cache headers is a huge one, and not at all reliable. Some recent estimates by performance optimization specialists have suggested as much as 70% of scripts across the internet are not served with proper caching headers, which means that such scripts would be completely ineffective if loaded using this (or a similar) technique. The script resource would end up being loaded completely a second-time, and the "near immediate" execution would obviously be false, and thus race conditions would ensue.

It's important to note at this point that the new <link rel=prefetch> facility has been suggested as a better workaround, but it suffers the same ill-fated assumption of script cacheability. Still others have suggested "new Image().src=..." or the [http://www.phpied.com/preload-then-execute/ <object> preloading trick] suggested by Stoyan Stefanov. Again, these tricks unwisely assume cacheability, for the "preloading" trick to solve the use-case in question.

=== At Risk ===
Currently, there are several large/popular web sites which are either currently (or who intend to soon) use LABjs in such a way as to run afoul of the new Gecko and Webkit behavioral changes with LABjs failing to operate properly. It's important to note that the problems of race conditions can be subtle and hard to detect, and so merely loading up such sites and failing to observe overt failure is not sufficient.

Sites which are known to have LABjs loading techniques in place with currently broken (or susceptible to such breakage in the near future) behavior are:

* [http://twitter.com Twitter]
* [http://zappos.com Zappos]
* [http://vimeo.com Vimeo]
* [http://mefeedia.com MeFeedia]
* [http://blog.getify.com Getify Solutions blog (my blog)]
* [http://flensed.com flensed Flash+JavaScript browser shims (cross-domain Ajax, cross-browser cookies, etc)]

Rather than getting hung up in the syntax of usage in LABjs that is or is not going to break, it's best to just think of the problem this way:

Does a site need to load more than one script, at least one of which comes from a remote domain location (like a CDN), and for which among the scripts there's at least one execution-order dependency among them? If so, then that site is susceptible to the current/future breakage if the HTML spec (and browsers) do not address this use case.

A common example (in use on many sites) of such might be loading:

* jQuery from the CDN
* jQuery-UI from the CDN
* plugins and usage code in one or more local files
* Google Analytics from the Google domain

Note that the emergence of popular script frameworks and their hosting on public CDN's is leading to more and more sites loading scripts from both local and remote locations, and also to loading more files that have dependencies (rather than the practice of concat'ing all files into one file to avoid dependency issues).

Any site which fits a profile like the above, and which might currently (many do), or in the future want to, use a script loader to improve their loading performance, will fail to achieve what they want cross-browser and in a performant way, if the HTML spec (and browsers) do not address the use case.

=== Benefits ===
The benefits of addressing both behaviors directly (without "preloading" tricks and bad assumption reliance) have been implied in the above discussion, but in short are:

a) clear and simplified code for script loaders, which leads to easier use by authors of more pages, which in turn leads to better web performance (as demonstrated clearly by intelligent script loading techniques as compared to just simple <script> tags in HTML markup)

b) full access to either/both of the execution-order behaviors (as the author sees fit), regardless of browser

c) avoiding reliance on bad assumptions (like cacheability) as a sufficient way to address the use-case

=== External Discussions of this Feature ===

* <cite>[http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html W3C public-html email thread]</cite>

* <cite>[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 W3C Bug #11295]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=620852 Mozilla Bug #620852]</cite>

* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>

* <cite>[http://hsivonen.iki.fi/script-execution/ HTML5 Script Execution Changes in Firefox 4 Beta 7]</cite>

* <cite>[http://blog.getify.com/2010/10/labjs-w3c-brief-update/ LABjs and W3C... brief update]</cite>

* <cite>[http://blog.getify.com/2010/10/ff4-script-loaders-and-order-preservation/ FF4, script loaders, and order preservation]</cite>

== Proposed Solutions ==

=== My Solution ===
The current proposal most well supported from the email discussion thread, and the one which I feel makes most sense, is described here.

The HTML spec already defines the "async" attribute for parser-inserted script tags, which when set to "true", changes their execution order behavior to be like script-inserted script-elements (in IE/Webkit), which is that they load in parallel and execute "as fast as possible" (ostensibly because the author is expressing no dependencies between multiple such "async"-marked scripts). Parser-inserted script elements without "async" (or with it set to false) behave as before and expected, which is that they load in parallel but execute in order.

However, the HTML spec does not define the "async" property (or any such behavior) for script-inserted script nodes (such as those created by a script loader). Instead, the spec implies that "async=true" like behavior is always true for such script-inserted script elements.

What is proposed is:

a) Script-inserted script elements should have (and respect the value of) an "async" property which is basically identical to the "async" attribute for parser-inserted script elements. That is, script elements with the "async" property set to "true" will behave accordingly, as will script elements with the "async" property set to false.

Essentially, the proposal is to mirror the "async" attribute behavior of parser-inserted script elements as an "async" property on script-inserted script elements. This has the benefit of using an existing facility and extending it (from current spec) in a way that is sensisble and symmetric with its current definition.
<blockquote style="background-color: #EFEFEF">
The scriptgroup or `readyState` alternate proposals allow for dependency management to be done in high-level code. The singular syncrhonized execution queue proposed here introduces artificial dependencies, undermining some of the benefits dynamic script loading provides.
</blockquote>

<blockquote style="background-color: #ccc;">
It's important to note that `async=false` scripts will load in a separate queue from `async=true` scripts. It's not that all scripts will now be forced into this insertion-order-execution queue. An author (or script loader) can chose which queue to put a script loading into based on the needs of the page and the resource. If I have a few scripts that are unrelated to each other and the main page (like Google Analytics, social sharing buttons, etc), I'll load those via `async=true`. For other scripts, where order matters for dependency sake, I'll use `async=false`. I think having both those queues available to high-level code is enough control over loading to serve the majority of use-cases pretty well.
<blockquote style="background-color: #EFEFEF">
If at any point these services begin dynamically loading `async=false` scripts of their own, they will begin blocking. This can lead to unexpected behavior of existing code as third-party libraries and services change. It would seem the specification should provide a means by which this blocking can be isolated to dependencies defined by the author and ordered execution not introduce conditions that allow unrelated libraries to affect this.
</blockquote>
</blockquote>

b) Furthermore, to aid in "feature-detection" of such new behavior, the proposal is to have the default value for the "async" property of script-inserted script elements be "true" (and of course the associated behavior thereof).

There are two major benefits to (b). One is that it provides a way to feature test such new behavior by not just looking for the existence of the "async" property on script elements, but specifically that the default value is "true" (which is opposite of what it would currently/normally be). Secondly, defaulting to "async=true" behavior for script-inserted script elements would preserve the default behavior of IE and Webkit, meaning there'd be less of a chance of breaking existing web content in either of those two browsers.

It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.

==== Proposal Amendment: Need Attribute/Property Semantic Inconsistency ====
In order to achieve consistency between the semantics of how the parser-inserted script element's `async` attribute and the script-inserted script element's `async` property behave, a slight change needs to be made to the value parsing/interpretation for parser-inserted script elements' `async` attribute.

If a parser-inserted script element has the `async` attribute present, but its value is exactly "false" (or any capitalization thereof), the script element should behave EXACTLY as if no `async` attribute were present.

If the attribute is present and either has no value, or has any other value except "false" (for instance, "true" or "async"), then it should be interpreted to be turning on "async" for that element.

Because it is highly unlikely (and indeed, quite irrational) that any existing web content is doing `async="false"` in HTML markup and yet still expecting "async" behavior to be turned on, it is pretty unlikely that this minor interpretation change will cause backwards-compatibility issues.
[[User:Getify|Getify]] 03:05, 22 December 2010 (UTC)

==== Proposal Amendment: Events ====
In addition to standardizing how scripts load and execute, it's also important to standardize the load and error events, and under what circumstances they fire, etc. Without reliable load/error events, the main proposal is not reliable and is thus unhelpful for the use-case.

A script-inserted script element must fire the "load" event only once, when:

a) immediately after the resource finishes loading, but before parsing/execution, AND

b) the script element loads any non-empty content (that is, it was a successful HTTP request), AND

c) the script element has either loaded from the remote location, or is loaded from the brower cache

Specifically, the script "load" event must come immediately between the script element finishing loading and the script element being parsed/executed. If the script resource successfully loads, nothing should interrupt the sequence of fininshing loading, the "load" event firing, and the script being parsed/executed.

A script-inserted script element must fire the "error" event only once, when:

a) immediately after a loading failure for the resource is detected (that is, an HTTP error received, such as 404, 500, 503, etc).

Either the "load" or "error" event, but not both, will fire, and only once, for every script-inserted script element.

NOTE: "load" and "error" events on script-inserted script elements must fire synchronously to ensure event reliability.

A case may be made for adding the "load" and "error" events as described here to parser-inserted script elements as well.

==== Processing Model ====
Script inserted script elements will have an "async" property that defaults to "true". If the author does not change the value, all such requested script loadings will be in their own "queue" and will default to "as fast as possible" execution behavior. For any script elements that the author sets "async=false", those scripts will load in a separate "queue", and will execute in insertion order only. Again, these two "queues" will operate strictly independent of each other.

==== Processing Model Details (without the event amendment) ====

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node.

When a previously-created script element node loses its parser-insertedness, if the element doesn't have the async content attribute, set the force-async flag to true and false otherwise.

When a script element node obtains the async content attribute (via setAttribute, setAttributeNode, setAttributeNS, by the fragment parser or the XSLTProcessor adding the attribute, etc.), set the force-async flag to false. (Note that calling removeAttribute("async") doesn't modify the force-async flag.)

The async IDL attribute must behave as follows:
* Upon setting, set the force-async flag to false and then reflect the async content attribute.
* Upon getting, if the force-async flag is true, return true. Otherwise, reflect the async content attribute.

In step 13. of http://www.whatwg.org/specs/web-apps/current-work/#running-a-script before the case "If the element has a src attribute" add a case:
If the script has a src attribute and the async IDL property getter returns false,
The element must be added to the queue of ordered script-inserted external scripts of the Document of the script element at the time the running a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run these steps:
# If the queue of ordered script-inserted external scripts is empty or the first script in the queue of ordered script-inserted external scripts has not been fetched yet, abort these steps.
# Execute the first script in the queue of ordered script-inserted external scripts.
# Remove the first script from queue of ordered script-inserted external scripts.
# Goto step #1.

Modify step 5 of http://www.whatwg.org/specs/web-apps/current-work/#the-end to say:
Spin the event loop until the set of scripts that will execute as soon as possible is empty and the queue of ordered script-inserted external scripts is empty.

==== Limitations ====
The two behaviors being identified solve either the case where no dependencies exist, or where a linear dependency chain exists (and which the script elements can be requested to execute in that order). It is possible that some authors have a more complex non-linear dependency chain that they would like to express. This would obviously require a much more complex API and spec change, and since that use-case has not (yet) surfaced as a particularly main-stream request, I believe it would be overengineering to try to address it with this proposed change set.

In addition, it's been duly noted that it's undesirable (and potentially confusing/problematic) to intentionally build in the inconsistency of having the "async" attribute (for parser-inserted scripts) and the "async" property (for script-inserted scripts) have different default values ("false" for the attribute, "true" for the property).

It's also been a point of discussion whether or not such a spec change has enough "carrot" to entice the browser vendors (namely IE and Webkit) to implement the behavior. Moreover, there's been some concern that if the default value for the "async" property were made to be "false" (like the attribute) to be more consistent and conservative, then it would possibly give the perception to IE and Webkit of "losing" some performance to cut out their default "as fast as possible" behavior.

=== Alternate Proposals ===
One early proposal on the email list was to introduce an entirely new property like "ordered" which an author could add to a script-inserted script element to instruct the browser to put it into the queue of execution-order-preserving script loadings. While such a property would address the use case, it introduces another property and thus more complicates the issue. It also fails to address the current spec inconsistency (which is confusing to new comers) that "async" is not a present/respected property in mirror of the attribute of the same name.

Another suggestion was a "waitFor" property that would be added to script elements and would specify a list of one or more DOM id's of other script elements that the current script should "wait for" in terms of execution. Again, this would solve the use case, but in a more complicated way, and there are concerns that it would be too confusing for the normal use-case.

Several suggestions have come in the form of creating explicit "preloading" (similar to <link rel=prefetch>), but as described above, "preloading" to solve this use case is a non-ideal hack and highly susceptible to breakage if the script fails to be sent with proper caching headers.

It's also been suggested that since this type of behavior is somewhat complicated, it may be better to intentionally obfuscate or complicate any such facility in the HTML, so as to make the barrier-to-entry rather high and force users to know what they are doing before doing it.

It's been suggested that "defer" already preserves execution order. However, "defer" is only defined for parser-inserted scripts, and thus is not applicable to the use-case in question from an on-demand point of view. Also, "defer" scripts explicitly way for DOMContentLoaded, even if they're ready to execute sooner. So this is less than desired.

Yet another proposal is a "document.executeScripts()" API, where an author can specify multiple sets of scripts that can load in parallel and it will enforce their execution order. A variation on that same idea was to use the "importScripts" from the Web Workers spec, however "importScripts" is synchronous (undesirable performance wise, obviously). The main downside (besides extra API complication) to "document.executeScripts()" is that there seem to be quite a few script execution properties/behaviors (including "document.currentScript" and charset override) which would have to be duplicated into this API facility.

==== "Script Group" element ====
One recent alternate proposal bears some special consideration, as it seems like it might be a decent option (although certainly more of a radical change for the spec and for browsers to implement). But it has the appearance of being pretty straightforward and semantic for authors to use, perhaps even more so than using "async".

The proposal is to create a new HTML element, called perhaps <scriptGroup>, <collection>, etc. Specifically, this element must be able to be inserted wherever a <script> element can currently be inserted. The "script group" element is intended to signify that all script elements added to it must perserve insertion execution order. This element wouldn't have much (but still some, explained in a moment) meaning in a parser-inserted context, since parser-inserted scripts already preserve order among themselves.

An advantage of the "script group" element would be to give a direct and easy way to attach event listeners ("load" and "error") to the entire group, rather than having to internally track events for each element if all you care about is the final "load" event, for instance. In the case of event handling, the "script group" element would have perhaps some benefit even in parser-inserted (markup) context.

The element would need to have an "id" property, and possibly attributes for "load" and "error" events.

A variation on how to look at this proposal is that a "script group" element could have an attribute/property on it (perhaps called "ordered") which would allow the group to either be order preserved or not. This would make the "script group" element much more useful in the parser-inserted context, as it would sort of be a shortcut to setting "async=true" on all the child script elements.

The "script group" element might look like this:

<scriptGroup id="group1">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

Or, with the "ordered" attribute to explicitly control ordering behavior for the group:

<scriptGroup id="group1" ordered="true">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

<scriptGroup id="group2" ordered="false" onload="alldone();">
<script src="baz.js"></script>
<script src="far.js"></script>
<script src="zab.js"></script>
</scriptGroup>

While the "script group" element is definitely more complicated to define and implement, it does have some semantic advantages for authors, and it also would significantly reduce the internal complexity of script loaders like LABjs. It would give authors (either directly or through script loaders) the flexibility to group scripts together into one of the two aforementioned behaviors (execution "as fast as possible" or "in insertion order"), and to easily access both behaviors in the same page.

==== Explicit support for "text/cache" MIME type behavior ====
Yet another alternate proposal has been suggested in the [[Talk:Dynamic_Script_Execution_Order]] thread.

Essentially, the proposal is that <script> tags directly support being declared with a `type` value of "text/cache". The behavior would be that the script resource is fetched, as the load events fired, as normal, but that the script itself would not be executed. Then later, at the desired time, the script in that element could be executed by changing the `type` value from "text/cache" to "text/javascript".

The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.
<blockquote style="background-color:#eee">
And does the onload event fire again after the script executes? <br/>
Or only when it's loaded? <br/>
Both seem to violate current `onload` semantics.
[[User:Serverherder|Serverherder]] 20:27, 15 December 2010 (UTC)

<blockquote style="background-color:#ccc">
As far as I'm concerned, I think the "load" event should happen immediately after a script loads, but before it executes, as I spell out in the [[Dynamic_Script_Execution_Order#Proposal_Amendment:_Events|Events proposal ammendment section]]. [[User:Getify|Getify]] 20:33, 15 December 2010 (UTC)
</blockquote>

</blockquote>

==== readyState "preloading" ====
Per the suggestion/comment added to the above [[Dynamic_Script_Execution_Order#Current_Limitations|Current Limitations]] section, it's been suggested that IE's current behavior with respect to the `readyState` property can adequately serve the use-case in question. This alternate proposal is very similar in spirit to the [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|previous section on explicit support for "text/cache"]] mime-type value.

The idea is that IE will begin fetching into the cache a script resource as soon as the `src` attribute of the dynamic script element is set. But IE will not execute the script (even if it finishes loading) until the script element is added to the DOM. However, the `readyState` property of the element, combined with the `onreadystatechange` handler listening for changes, can detect when the script has finished loading, by receiving the "loaded" value.

In this way, a script loader could "preload" a set of scripts all in parallel, but control their execution order by delaying the appending of the element to the DOM until execution is desired.

'''Update''' [[User:Getify|Getify]] 14:10, 20 December 2010 (UTC)

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

This seems to be the spec stating that browsers may do what IE's behavior on scripts does, which is to start fetching the resource once the `src` property is set, but not execute it until the script element is inserted into the DOM.

It would seem then that browsers could/should be petitioned to consider implementing this suggestion, perhaps taking the `readyState` implementation from IE as guidance. While I'm still not sure that this would be my preferred method of solving the overall use-case in discussion on this page, it would be an option for such, and it would also help other use-cases, such as those being discussed in this W3C public-html thread:

[http://lists.w3.org/Archives/Public/public-html/2010Dec/0174.html Need to: "preload" CSS and JS]

[[Category:Feature Request|Dynamic Script Execution Order]]

Dynamic Script Execution Order

2010-12-22T03:05:57Z

Getify: adding proposal amendment: regarding async attribute/property consistency

This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.

Briefly, this issue has arisen because recent "nightlies" changes in both Mozilla Gecko and Webkit have broken the ability for script-loaders like [http://labjs.com LABjs] to be able to download scripts in parallel but ensure their execution order. As a result of the discussion, it's become apparent that both the spec for, and various current browser implementations around, dynamic script loading is incomplete in addressing this use case, and that some change needs to occur.

There is one main proposal that has surfaced from the discussions, with several other alternatives having been discussed. This page will try to distill the long email thread down and clearly present the main proposal, objections, and alternative suggestions.

Please feel free to join the discussion of this topic in the [[Talk:Dynamic_Script_Execution_Order]] area.

== Use Case Description ==
Script tags/elements can either:

a) appear in the HTML markup ("parser-inserted"), OR

b) be dynamically appended to the DOM using document.createElement() ("script-inserted")

Parser-inserted script tags, up until recent browser versions, had the undesirable performance behavior of loading and executing serially, blocking everything else while doing so. Recently, many browsers have improved the situation by loading the scripts in parallel, but still executing them in order.

On-demand (or dynamic) script loading has emerged in recent years for a variety of different reasons, most notably the performance improvements to address such concerns. It is desired by many different scenarios to be able to download scripts to a page completely independently of the loading of the rest of a page's resources, or even well after a page has finished loading ("on-demand").

Recent additions to HTML spec such as "defer" and "async" were intended to address the use-case for parser-inserted script elements, but their behaviors have been unhelpful for the on-demand loading use-case (script-inserted script elements).

Thus, script loaders (like [http://labjs.com LABjs]) were developed to give page authors an easy way to specify one or more scripts to load (regardless of when in the life-time of the page that loading is requested), and for as many of them as possible to load in parallel, and for those scripts to be loadable from any local or remote domain location, and for the script loader to be able to control the execution order (if the usage of the script loader's API expresses the need to) to preserve dependencies between the scripts.

Sometimes, dynamic script loading is used to load totally independent scripts, and thus "as fast as possible" execution is desired. Other times (and possibly more frequently), multiple scripts are loaded with some dependencies among them, requiring them to execute in a certain order.

What is needed is some facility by which a script loader can express that dynamic script loading either does or does not need execution order preserved among the queue of requested script loadings.

=== Current Limitations ===
Unfortunately, browser behavior around script-inserted script elements and their loading and execution behavior is splintered. There are, at present, two main camps of behavior:

a) in IE and Webkit (including Chrome), the default behavior for script-inserted script elements is for them all to execute in "as fast as possible" mode, meaning there's no guarantee about ordering. This effectively makes on-demand (dynamic) script loading impossible to work in parallel-mode if the resources in question have dependencies -- the only straight-forward way to handle things is to load each file and execute, serially, losing the parallel loading performance benefits.
<blockquote style="background-color: #EEEEEE">
I'm not sure if this is the case.

IE will start fetching resources without execution simply by setting the src attribute. Scripts will not execute, however, until they are added to the document. Since IE supports the readyState attribute and readystatechange event, it's possible to load scripts in parallel and execute them in order without resorting to invalid type attribute hack-ery.

<pre style="background-color:white" lang="javascript">
script= document.createElement("SCRIPT");
script.onreadystatechange= function(){
if(this.readyState == 'loaded')
/*
Network fetch is now complete, following
triggers synchronous execution.
*/
document.body.appendChild(this);
else if(this.readyState == "complete")
this.onreadystatechange= null;
}
script.src= "foo.js";
/* Network fetching begins now */
</pre>
</blockquote>

<blockquote style="background-color: #ccc">
I've experimented with such things heavily in the past, and I'm fairly suspicious that this is not reliable across various versions of IE (6-9), nor does it work reliably the same depending on if an element is already in the browser cache or not. I'm not 100% certain that what you suggest is flawed, but I have a strong hunch that it can be shown to have some holes in it for IE loading. I will try to create some test cases to prove or disprove.
<blockquote style="background-color: #EEEEEE">
When loading a script that is in the cache, IE requires the event handler be installed prior to setting the `src` attribute. Otherwise the element's transition to the "loaded" state will be missed. IE routinely "skips" ready state transitions when cached scripts are immediately inserted into the DOM so suspicion is understandable; however, delayed insertion works around this "problem". The script above has been tested in IE6-8 with scripts in a variety of caching states and found to work correctly.
</blockquote>

Moreover, you're suggesting something that is AFAIK only IE right now, and definitely appears to not be standardized. In the same way that I'm hesitant to continue pinning loading behavior on hacks like the invalid type attribute value, I wouldn't want to approach loading with this technique (even if it were proven reliable on all IE's under all caching circumstances) unless it was a serious proposal to the W3C to have this technique be the new standard (as opposed to the current proposal, as implemented by Mozilla and Webkit now).
<blockquote style="background-color: #EEEEEE">
I think you're right: Only IE impelements this event and property on script elements. The readystatechange event, however, is widely understood due to the XmlHttpRequest implementation and `readyState` property has been added to the `document` in WebKit, Mozilla and IE.
</blockquote>

That having been said, I think this is at least a viable candidate for "Alternate Proposals" and deserves to be listed as such. As always, I welcome input from the community on all the ideas presented here, including this one. But, since the main proposal (async=false) is already being implemented by at least two major browsers, I'm not sure if the tide will be changed or not.

</blockquote>

<blockquote style="background-color:#ddd;">
Also, the suggestion of handling the "preload" and deferred execution via the script tag's `readyState` property is very similar in spirit to the suggestion that was made to explicitly support [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|preloading into cache without execution]]. As I said, either of those two approaches might work, but they both put more of the onus of complexity in managing multiple dependencies on the high-level code (author, script loader, etc). I'm more in favor of this functionality being explicitly built-in natively into the queues. As always, I welcome comments to any side of this discussion.

[[User:Getify|Getify]] 18:35, 15 December 2010 (UTC)
</blockquote>

b) in Gecko and Opera, the default behavior for script-inserted script elements is for them all to load in parallel, but execute serially in insertion order. Technically, this makes it impossible to dynamically load independent script elements and have them execute in "as fast as possible" mode.

As described above, both behaviors are desirable under different circumstances, but each of the two camps provides only one behavior, and no way to straightforwardly achieve the other. This obviously creates a big nightmare interoperability-wise when trying to provide a general script loader cross-browser.

Since it is observed that the behavior in (a) is more detrimental (race-condition wise) for the case where dependencies exist, script loaders like LABjs had to find some way around this problem while still attempting the best possible parallel loading performance. However, the trick used is hacky and not completely reliable -- yet it is the best way to solve the use-case in <s>IE and </s>Webkit.

For Gecko/Opera, the concession was just (silently) made that the lesser-common use case of "as fast as possible" wasn't possible, but degraded fine to "insertion order execution", while keeping the parallel loading benefits.

<blockquote style="background-color: #EEEEEE">
Gecko's strict execution order creates dependencies between scripts which are unrelated and prevents the ability mitigate the impact of server outages / network latency. This is exacerbated by the fact that Gecko, unlike IE and WebKit, provides no mechanism to <b>remove</b> scripts from the execution queue.

Consider the case where JSONP is used to provide auto-completion. The user types "hello" and the JSONP request is made; however, the "currently" loading script is out-of-date as soon as the user modifies his search to "hello world". Gecko's algorithm requires the out-of-date request load and execute before the second request.
</blockquote>

Recently, Gecko landed a [http://hg.mozilla.org/mozilla-central/rev/a60414d076b5 patch] to the trunk that stopped Gecko's existing behavior of preserving execution order, making script-inserted script elements now execute in "as fast as possible" mode similiar to IE/Webkit. Unfortunately, the "workaround" used in IE/Webkit (described in the next section) for dealing with parallel loading and execution-order dependencies does not work in Gecko, which means presently the use-case in question is now broken in Gecko trunk/FF4 nightlies.

Moreover, Webkit recently landed a [http://trac.webkit.org/changeset/67245 patch] to the trunk that stopped Webkit's non-standard but long-held behavior (also used in the "workaround" described in the next section) of loading into cache script resources with an unrecognized "type" value, but silently not executing them. This behvaior (while hacky) is central to being able to address the use-case in question in Webkit, so at present, Webkit nightlies are now also entirely broken on the use-case (though in a different way than Gecko).

Both the Gecko change and the Webkit change are well-intentioned, as they are bringing the respective browser more in line with the HTML spec. However, what's really been demonstrated is that the HTML spec is not properly handling this use-case, and so the goal is not to address the browser issues raised with more awkward hacks, but to address the shortcomings of the spec first, and then encourage all browsers to adhere to such.

<blockquote style="background-color: #EEEEEE">
Considering Internet Explorer's readyState implementation provides a means of both parallel loading and preserving execution order can be achieved, perhaps its "readyState" property and onreadystatechange event should be included.
</blockquote>

=== Current Usage and Workarounds ===
To work around the limitation in IE/Webkit(prior to the above noted patch) of not being able to rely on script order execution for parallel loaded scripts, a "preloading" trick was developed. This trick relied on non-standard (but long-held) behavior in these browsers that a script-inserted script element with an unrecognized "type" value (such as "script/cache") would be fetched/loaded, but would not execute. This had the effect of loading the resource into cache, and then firing the "load" handlers to let the page know when the resource was completely in cache.

Assuming that the resource was served with proper caching headers, and was in fact in the cache, it could then be executed (nearly) immediately when it was the proper execution order time by re-requesting the same resource via another script-inserted script element with the proper "text/javascript" type value, pulling the resource from the cache and executing it, without another server round-trip.

Of course, the assumption of proper cache headers is a huge one, and not at all reliable. Some recent estimates by performance optimization specialists have suggested as much as 70% of scripts across the internet are not served with proper caching headers, which means that such scripts would be completely ineffective if loaded using this (or a similar) technique. The script resource would end up being loaded completely a second-time, and the "near immediate" execution would obviously be false, and thus race conditions would ensue.

It's important to note at this point that the new <link rel=prefetch> facility has been suggested as a better workaround, but it suffers the same ill-fated assumption of script cacheability. Still others have suggested "new Image().src=..." or the [http://www.phpied.com/preload-then-execute/ <object> preloading trick] suggested by Stoyan Stefanov. Again, these tricks unwisely assume cacheability, for the "preloading" trick to solve the use-case in question.

=== At Risk ===
Currently, there are several large/popular web sites which are either currently (or who intend to soon) use LABjs in such a way as to run afoul of the new Gecko and Webkit behavioral changes with LABjs failing to operate properly. It's important to note that the problems of race conditions can be subtle and hard to detect, and so merely loading up such sites and failing to observe overt failure is not sufficient.

Sites which are known to have LABjs loading techniques in place with currently broken (or susceptible to such breakage in the near future) behavior are:

* [http://twitter.com Twitter]
* [http://zappos.com Zappos]
* [http://vimeo.com Vimeo]
* [http://mefeedia.com MeFeedia]
* [http://blog.getify.com Getify Solutions blog (my blog)]
* [http://flensed.com flensed Flash+JavaScript browser shims (cross-domain Ajax, cross-browser cookies, etc)]

Rather than getting hung up in the syntax of usage in LABjs that is or is not going to break, it's best to just think of the problem this way:

Does a site need to load more than one script, at least one of which comes from a remote domain location (like a CDN), and for which among the scripts there's at least one execution-order dependency among them? If so, then that site is susceptible to the current/future breakage if the HTML spec (and browsers) do not address this use case.

A common example (in use on many sites) of such might be loading:

* jQuery from the CDN
* jQuery-UI from the CDN
* plugins and usage code in one or more local files
* Google Analytics from the Google domain

Note that the emergence of popular script frameworks and their hosting on public CDN's is leading to more and more sites loading scripts from both local and remote locations, and also to loading more files that have dependencies (rather than the practice of concat'ing all files into one file to avoid dependency issues).

Any site which fits a profile like the above, and which might currently (many do), or in the future want to, use a script loader to improve their loading performance, will fail to achieve what they want cross-browser and in a performant way, if the HTML spec (and browsers) do not address the use case.

=== Benefits ===
The benefits of addressing both behaviors directly (without "preloading" tricks and bad assumption reliance) have been implied in the above discussion, but in short are:

a) clear and simplified code for script loaders, which leads to easier use by authors of more pages, which in turn leads to better web performance (as demonstrated clearly by intelligent script loading techniques as compared to just simple <script> tags in HTML markup)

b) full access to either/both of the execution-order behaviors (as the author sees fit), regardless of browser

c) avoiding reliance on bad assumptions (like cacheability) as a sufficient way to address the use-case

=== External Discussions of this Feature ===

* <cite>[http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html W3C public-html email thread]</cite>

* <cite>[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 W3C Bug #11295]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>

* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>

* <cite>[http://hsivonen.iki.fi/script-execution/ HTML5 Script Execution Changes in Firefox 4 Beta 7]</cite>

* <cite>[http://blog.getify.com/2010/10/labjs-w3c-brief-update/ LABjs and W3C... brief update]</cite>

* <cite>[http://blog.getify.com/2010/10/ff4-script-loaders-and-order-preservation/ FF4, script loaders, and order preservation]</cite>

== Proposed Solutions ==

=== My Solution ===
The current proposal most well supported from the email discussion thread, and the one which I feel makes most sense, is described here.

The HTML spec already defines the "async" attribute for parser-inserted script tags, which when set to "true", changes their execution order behavior to be like script-inserted script-elements (in IE/Webkit), which is that they load in parallel and execute "as fast as possible" (ostensibly because the author is expressing no dependencies between multiple such "async"-marked scripts). Parser-inserted script elements without "async" (or with it set to false) behave as before and expected, which is that they load in parallel but execute in order.

However, the HTML spec does not define the "async" property (or any such behavior) for script-inserted script nodes (such as those created by a script loader). Instead, the spec implies that "async=true" like behavior is always true for such script-inserted script elements.

What is proposed is:

a) Script-inserted script elements should have (and respect the value of) an "async" property which is basically identical to the "async" attribute for parser-inserted script elements. That is, script elements with the "async" property set to "true" will behave accordingly, as will script elements with the "async" property set to false.

Essentially, the proposal is to mirror the "async" attribute behavior of parser-inserted script elements as an "async" property on script-inserted script elements. This has the benefit of using an existing facility and extending it (from current spec) in a way that is sensisble and symmetric with its current definition.
<blockquote style="background-color: #EFEFEF">
The scriptgroup or `readyState` alternate proposals allow for dependency management to be done in high-level code. The singular syncrhonized execution queue proposed here introduces artificial dependencies, undermining some of the benefits dynamic script loading provides.
</blockquote>

<blockquote style="background-color: #ccc;">
It's important to note that `async=false` scripts will load in a separate queue from `async=true` scripts. It's not that all scripts will now be forced into this insertion-order-execution queue. An author (or script loader) can chose which queue to put a script loading into based on the needs of the page and the resource. If I have a few scripts that are unrelated to each other and the main page (like Google Analytics, social sharing buttons, etc), I'll load those via `async=true`. For other scripts, where order matters for dependency sake, I'll use `async=false`. I think having both those queues available to high-level code is enough control over loading to serve the majority of use-cases pretty well.
<blockquote style="background-color: #EFEFEF">
If at any point these services begin dynamically loading `async=false` scripts of their own, they will begin blocking. This can lead to unexpected behavior of existing code as third-party libraries and services change. It would seem the specification should provide a means by which this blocking can be isolated to dependencies defined by the author and ordered execution not introduce conditions that allow unrelated libraries to affect this.
</blockquote>
</blockquote>

b) Furthermore, to aid in "feature-detection" of such new behavior, the proposal is to have the default value for the "async" property of script-inserted script elements be "true" (and of course the associated behavior thereof).

There are two major benefits to (b). One is that it provides a way to feature test such new behavior by not just looking for the existence of the "async" property on script elements, but specifically that the default value is "true" (which is opposite of what it would currently/normally be). Secondly, defaulting to "async=true" behavior for script-inserted script elements would preserve the default behavior of IE and Webkit, meaning there'd be less of a chance of breaking existing web content in either of those two browsers.

It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.

==== Proposal Amendment: Need Attribute/Property Semantic Inconsistency ====
In order to achieve consistency between the semantics of how the parser-inserted script element's `async` attribute and the script-inserted script element's `async` property behave, a slight change needs to be made to the value parsing/interpretation for parser-inserted script elements' `async` attribute.

If a parser-inserted script element has the `async` attribute present, but its value is exactly "false" (or any capitalization thereof), the script element should behave EXACTLY as if no `async` attribute were present.

If the attribute is present and either has no value, or has any other value except "false" (for instance, "true" or "async"), then it should be interpreted to be turning on "async" for that element.

Because it is highly unlikely (and indeed, quite irrational) that any existing web content is doing `async="false"` in HTML markup and yet still expecting "async" behavior to be turned on, it is pretty unlikely that this minor interpretation change will cause backwards-compatibility issues.
[[User:Getify|Getify]] 03:05, 22 December 2010 (UTC)

==== Proposal Amendment: Events ====
In addition to standardizing how scripts load and execute, it's also important to standardize the load and error events, and under what circumstances they fire, etc. Without reliable load/error events, the main proposal is not reliable and is thus unhelpful for the use-case.

A script-inserted script element must fire the "load" event only once, when:

a) immediately after the resource finishes loading, but before parsing/execution, AND

b) the script element loads any non-empty content (that is, it was a successful HTTP request), AND

c) the script element has either loaded from the remote location, or is loaded from the brower cache

Specifically, the script "load" event must come immediately between the script element finishing loading and the script element being parsed/executed. If the script resource successfully loads, nothing should interrupt the sequence of fininshing loading, the "load" event firing, and the script being parsed/executed.

A script-inserted script element must fire the "error" event only once, when:

a) immediately after a loading failure for the resource is detected (that is, an HTTP error received, such as 404, 500, 503, etc).

Either the "load" or "error" event, but not both, will fire, and only once, for every script-inserted script element.

NOTE: "load" and "error" events on script-inserted script elements must fire synchronously to ensure event reliability.

A case may be made for adding the "load" and "error" events as described here to parser-inserted script elements as well.

==== Processing Model ====
Script inserted script elements will have an "async" property that defaults to "true". If the author does not change the value, all such requested script loadings will be in their own "queue" and will default to "as fast as possible" execution behavior. For any script elements that the author sets "async=false", those scripts will load in a separate "queue", and will execute in insertion order only. Again, these two "queues" will operate strictly independent of each other.

==== Processing Model Details (without the event amendment) ====

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node.

When a previously-created script element node loses its parser-insertedness, if the element doesn't have the async content attribute, set the force-async flag to true and false otherwise.

When a script element node obtains the async content attribute (via setAttribute, setAttributeNode, setAttributeNS, by the fragment parser or the XSLTProcessor adding the attribute, etc.), set the force-async flag to false. (Note that calling removeAttribute("async") doesn't modify the force-async flag.)

The async IDL attribute must behave as follows:
* Upon setting, set the force-async flag to false and then reflect the async content attribute.
* Upon getting, if the force-async flag is true, return true. Otherwise, reflect the async content attribute.

In step 13. of http://www.whatwg.org/specs/web-apps/current-work/#running-a-script before the case "If the element has a src attribute" add a case:
If the script has a src attribute and the async IDL property getter returns false,
The element must be added to the queue of ordered script-inserted external scripts of the Document of the script element at the time the running a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run these steps:
# If the queue of ordered script-inserted external scripts is empty or the first script in the queue of ordered script-inserted external scripts has not been fetched yet, abort these steps.
# Execute the first script in the queue of ordered script-inserted external scripts.
# Remove the first script from queue of ordered script-inserted external scripts.
# Goto step #1.

Modify step 5 of http://www.whatwg.org/specs/web-apps/current-work/#the-end to say:
Spin the event loop until the set of scripts that will execute as soon as possible is empty and the queue of ordered script-inserted external scripts is empty.

==== Limitations ====
The two behaviors being identified solve either the case where no dependencies exist, or where a linear dependency chain exists (and which the script elements can be requested to execute in that order). It is possible that some authors have a more complex non-linear dependency chain that they would like to express. This would obviously require a much more complex API and spec change, and since that use-case has not (yet) surfaced as a particularly main-stream request, I believe it would be overengineering to try to address it with this proposed change set.

In addition, it's been duly noted that it's undesirable (and potentially confusing/problematic) to intentionally build in the inconsistency of having the "async" attribute (for parser-inserted scripts) and the "async" property (for script-inserted scripts) have different default values ("false" for the attribute, "true" for the property).

It's also been a point of discussion whether or not such a spec change has enough "carrot" to entice the browser vendors (namely IE and Webkit) to implement the behavior. Moreover, there's been some concern that if the default value for the "async" property were made to be "false" (like the attribute) to be more consistent and conservative, then it would possibly give the perception to IE and Webkit of "losing" some performance to cut out their default "as fast as possible" behavior.

=== Alternate Proposals ===
One early proposal on the email list was to introduce an entirely new property like "ordered" which an author could add to a script-inserted script element to instruct the browser to put it into the queue of execution-order-preserving script loadings. While such a property would address the use case, it introduces another property and thus more complicates the issue. It also fails to address the current spec inconsistency (which is confusing to new comers) that "async" is not a present/respected property in mirror of the attribute of the same name.

Another suggestion was a "waitFor" property that would be added to script elements and would specify a list of one or more DOM id's of other script elements that the current script should "wait for" in terms of execution. Again, this would solve the use case, but in a more complicated way, and there are concerns that it would be too confusing for the normal use-case.

Several suggestions have come in the form of creating explicit "preloading" (similar to <link rel=prefetch>), but as described above, "preloading" to solve this use case is a non-ideal hack and highly susceptible to breakage if the script fails to be sent with proper caching headers.

It's also been suggested that since this type of behavior is somewhat complicated, it may be better to intentionally obfuscate or complicate any such facility in the HTML, so as to make the barrier-to-entry rather high and force users to know what they are doing before doing it.

It's been suggested that "defer" already preserves execution order. However, "defer" is only defined for parser-inserted scripts, and thus is not applicable to the use-case in question from an on-demand point of view. Also, "defer" scripts explicitly way for DOMContentLoaded, even if they're ready to execute sooner. So this is less than desired.

Yet another proposal is a "document.executeScripts()" API, where an author can specify multiple sets of scripts that can load in parallel and it will enforce their execution order. A variation on that same idea was to use the "importScripts" from the Web Workers spec, however "importScripts" is synchronous (undesirable performance wise, obviously). The main downside (besides extra API complication) to "document.executeScripts()" is that there seem to be quite a few script execution properties/behaviors (including "document.currentScript" and charset override) which would have to be duplicated into this API facility.

==== "Script Group" element ====
One recent alternate proposal bears some special consideration, as it seems like it might be a decent option (although certainly more of a radical change for the spec and for browsers to implement). But it has the appearance of being pretty straightforward and semantic for authors to use, perhaps even more so than using "async".

The proposal is to create a new HTML element, called perhaps <scriptGroup>, <collection>, etc. Specifically, this element must be able to be inserted wherever a <script> element can currently be inserted. The "script group" element is intended to signify that all script elements added to it must perserve insertion execution order. This element wouldn't have much (but still some, explained in a moment) meaning in a parser-inserted context, since parser-inserted scripts already preserve order among themselves.

An advantage of the "script group" element would be to give a direct and easy way to attach event listeners ("load" and "error") to the entire group, rather than having to internally track events for each element if all you care about is the final "load" event, for instance. In the case of event handling, the "script group" element would have perhaps some benefit even in parser-inserted (markup) context.

The element would need to have an "id" property, and possibly attributes for "load" and "error" events.

A variation on how to look at this proposal is that a "script group" element could have an attribute/property on it (perhaps called "ordered") which would allow the group to either be order preserved or not. This would make the "script group" element much more useful in the parser-inserted context, as it would sort of be a shortcut to setting "async=true" on all the child script elements.

The "script group" element might look like this:

<scriptGroup id="group1">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

Or, with the "ordered" attribute to explicitly control ordering behavior for the group:

<scriptGroup id="group1" ordered="true">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

<scriptGroup id="group2" ordered="false" onload="alldone();">
<script src="baz.js"></script>
<script src="far.js"></script>
<script src="zab.js"></script>
</scriptGroup>

While the "script group" element is definitely more complicated to define and implement, it does have some semantic advantages for authors, and it also would significantly reduce the internal complexity of script loaders like LABjs. It would give authors (either directly or through script loaders) the flexibility to group scripts together into one of the two aforementioned behaviors (execution "as fast as possible" or "in insertion order"), and to easily access both behaviors in the same page.

==== Explicit support for "text/cache" MIME type behavior ====
Yet another alternate proposal has been suggested in the [[Talk:Dynamic_Script_Execution_Order]] thread.

Essentially, the proposal is that <script> tags directly support being declared with a `type` value of "text/cache". The behavior would be that the script resource is fetched, as the load events fired, as normal, but that the script itself would not be executed. Then later, at the desired time, the script in that element could be executed by changing the `type` value from "text/cache" to "text/javascript".

The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.
<blockquote style="background-color:#eee">
And does the onload event fire again after the script executes? <br/>
Or only when it's loaded? <br/>
Both seem to violate current `onload` semantics.
[[User:Serverherder|Serverherder]] 20:27, 15 December 2010 (UTC)

<blockquote style="background-color:#ccc">
As far as I'm concerned, I think the "load" event should happen immediately after a script loads, but before it executes, as I spell out in the [[Dynamic_Script_Execution_Order#Proposal_Amendment:_Events|Events proposal ammendment section]]. [[User:Getify|Getify]] 20:33, 15 December 2010 (UTC)
</blockquote>

</blockquote>

==== readyState "preloading" ====
Per the suggestion/comment added to the above [[Dynamic_Script_Execution_Order#Current_Limitations|Current Limitations]] section, it's been suggested that IE's current behavior with respect to the `readyState` property can adequately serve the use-case in question. This alternate proposal is very similar in spirit to the [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|previous section on explicit support for "text/cache"]] mime-type value.

The idea is that IE will begin fetching into the cache a script resource as soon as the `src` attribute of the dynamic script element is set. But IE will not execute the script (even if it finishes loading) until the script element is added to the DOM. However, the `readyState` property of the element, combined with the `onreadystatechange` handler listening for changes, can detect when the script has finished loading, by receiving the "loaded" value.

In this way, a script loader could "preload" a set of scripts all in parallel, but control their execution order by delaying the appending of the element to the DOM until execution is desired.

'''Update''' [[User:Getify|Getify]] 14:10, 20 December 2010 (UTC)

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

This seems to be the spec stating that browsers may do what IE's behavior on scripts does, which is to start fetching the resource once the `src` property is set, but not execute it until the script element is inserted into the DOM.

It would seem then that browsers could/should be petitioned to consider implementing this suggestion, perhaps taking the `readyState` implementation from IE as guidance. While I'm still not sure that this would be my preferred method of solving the overall use-case in discussion on this page, it would be an option for such, and it would also help other use-cases, such as those being discussed in this W3C public-html thread:

[http://lists.w3.org/Archives/Public/public-html/2010Dec/0174.html Need to: "preload" CSS and JS]

[[Category:Feature Request|Dynamic Script Execution Order]]

Dynamic Script Execution Order

2010-12-20T14:10:58Z

Getify: adding comment about spec's support for the `readyState` proposal

This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.

Briefly, this issue has arisen because recent "nightlies" changes in both Mozilla Gecko and Webkit have broken the ability for script-loaders like [http://labjs.com LABjs] to be able to download scripts in parallel but ensure their execution order. As a result of the discussion, it's become apparent that both the spec for, and various current browser implementations around, dynamic script loading is incomplete in addressing this use case, and that some change needs to occur.

There is one main proposal that has surfaced from the discussions, with several other alternatives having been discussed. This page will try to distill the long email thread down and clearly present the main proposal, objections, and alternative suggestions.

Please feel free to join the discussion of this topic in the [[Talk:Dynamic_Script_Execution_Order]] area.

== Use Case Description ==
Script tags/elements can either:

a) appear in the HTML markup ("parser-inserted"), OR

b) be dynamically appended to the DOM using document.createElement() ("script-inserted")

Parser-inserted script tags, up until recent browser versions, had the undesirable performance behavior of loading and executing serially, blocking everything else while doing so. Recently, many browsers have improved the situation by loading the scripts in parallel, but still executing them in order.

On-demand (or dynamic) script loading has emerged in recent years for a variety of different reasons, most notably the performance improvements to address such concerns. It is desired by many different scenarios to be able to download scripts to a page completely independently of the loading of the rest of a page's resources, or even well after a page has finished loading ("on-demand").

Recent additions to HTML spec such as "defer" and "async" were intended to address the use-case for parser-inserted script elements, but their behaviors have been unhelpful for the on-demand loading use-case (script-inserted script elements).

Thus, script loaders (like [http://labjs.com LABjs]) were developed to give page authors an easy way to specify one or more scripts to load (regardless of when in the life-time of the page that loading is requested), and for as many of them as possible to load in parallel, and for those scripts to be loadable from any local or remote domain location, and for the script loader to be able to control the execution order (if the usage of the script loader's API expresses the need to) to preserve dependencies between the scripts.

Sometimes, dynamic script loading is used to load totally independent scripts, and thus "as fast as possible" execution is desired. Other times (and possibly more frequently), multiple scripts are loaded with some dependencies among them, requiring them to execute in a certain order.

What is needed is some facility by which a script loader can express that dynamic script loading either does or does not need execution order preserved among the queue of requested script loadings.

=== Current Limitations ===
Unfortunately, browser behavior around script-inserted script elements and their loading and execution behavior is splintered. There are, at present, two main camps of behavior:

a) in IE and Webkit (including Chrome), the default behavior for script-inserted script elements is for them all to execute in "as fast as possible" mode, meaning there's no guarantee about ordering. This effectively makes on-demand (dynamic) script loading impossible to work in parallel-mode if the resources in question have dependencies -- the only straight-forward way to handle things is to load each file and execute, serially, losing the parallel loading performance benefits.
<blockquote style="background-color: #EEEEEE">
I'm not sure if this is the case.

IE will start fetching resources without execution simply by setting the src attribute. Scripts will not execute, however, until they are added to the document. Since IE supports the readyState attribute and readystatechange event, it's possible to load scripts in parallel and execute them in order without resorting to invalid type attribute hack-ery.

<pre style="background-color:white" lang="javascript">
script= document.createElement("SCRIPT");
script.onreadystatechange= function(){
if(this.readyState == 'loaded')
/*
Network fetch is now complete, following
triggers synchronous execution.
*/
document.body.appendChild(this);
else if(this.readyState == "complete")
this.onreadystatechange= null;
}
script.src= "foo.js";
/* Network fetching begins now */
</pre>
</blockquote>

<blockquote style="background-color: #ccc">
I've experimented with such things heavily in the past, and I'm fairly suspicious that this is not reliable across various versions of IE (6-9), nor does it work reliably the same depending on if an element is already in the browser cache or not. I'm not 100% certain that what you suggest is flawed, but I have a strong hunch that it can be shown to have some holes in it for IE loading. I will try to create some test cases to prove or disprove.
<blockquote style="background-color: #EEEEEE">
When loading a script that is in the cache, IE requires the event handler be installed prior to setting the `src` attribute. Otherwise the element's transition to the "loaded" state will be missed. IE routinely "skips" ready state transitions when cached scripts are immediately inserted into the DOM so suspicion is understandable; however, delayed insertion works around this "problem". The script above has been tested in IE6-8 with scripts in a variety of caching states and found to work correctly.
</blockquote>

Moreover, you're suggesting something that is AFAIK only IE right now, and definitely appears to not be standardized. In the same way that I'm hesitant to continue pinning loading behavior on hacks like the invalid type attribute value, I wouldn't want to approach loading with this technique (even if it were proven reliable on all IE's under all caching circumstances) unless it was a serious proposal to the W3C to have this technique be the new standard (as opposed to the current proposal, as implemented by Mozilla and Webkit now).
<blockquote style="background-color: #EEEEEE">
I think you're right: Only IE impelements this event and property on script elements. The readystatechange event, however, is widely understood due to the XmlHttpRequest implementation and `readyState` property has been added to the `document` in WebKit, Mozilla and IE.
</blockquote>

That having been said, I think this is at least a viable candidate for "Alternate Proposals" and deserves to be listed as such. As always, I welcome input from the community on all the ideas presented here, including this one. But, since the main proposal (async=false) is already being implemented by at least two major browsers, I'm not sure if the tide will be changed or not.

</blockquote>

<blockquote style="background-color:#ddd;">
Also, the suggestion of handling the "preload" and deferred execution via the script tag's `readyState` property is very similar in spirit to the suggestion that was made to explicitly support [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|preloading into cache without execution]]. As I said, either of those two approaches might work, but they both put more of the onus of complexity in managing multiple dependencies on the high-level code (author, script loader, etc). I'm more in favor of this functionality being explicitly built-in natively into the queues. As always, I welcome comments to any side of this discussion.

[[User:Getify|Getify]] 18:35, 15 December 2010 (UTC)
</blockquote>

b) in Gecko and Opera, the default behavior for script-inserted script elements is for them all to load in parallel, but execute serially in insertion order. Technically, this makes it impossible to dynamically load independent script elements and have them execute in "as fast as possible" mode.

As described above, both behaviors are desirable under different circumstances, but each of the two camps provides only one behavior, and no way to straightforwardly achieve the other. This obviously creates a big nightmare interoperability-wise when trying to provide a general script loader cross-browser.

Since it is observed that the behavior in (a) is more detrimental (race-condition wise) for the case where dependencies exist, script loaders like LABjs had to find some way around this problem while still attempting the best possible parallel loading performance. However, the trick used is hacky and not completely reliable -- yet it is the best way to solve the use-case in <s>IE and </s>Webkit.

For Gecko/Opera, the concession was just (silently) made that the lesser-common use case of "as fast as possible" wasn't possible, but degraded fine to "insertion order execution", while keeping the parallel loading benefits.

<blockquote style="background-color: #EEEEEE">
Gecko's strict execution order creates dependencies between scripts which are unrelated and prevents the ability mitigate the impact of server outages / network latency. This is exacerbated by the fact that Gecko, unlike IE and WebKit, provides no mechanism to <b>remove</b> scripts from the execution queue.

Consider the case where JSONP is used to provide auto-completion. The user types "hello" and the JSONP request is made; however, the "currently" loading script is out-of-date as soon as the user modifies his search to "hello world". Gecko's algorithm requires the out-of-date request load and execute before the second request.
</blockquote>

Recently, Gecko landed a [http://hg.mozilla.org/mozilla-central/rev/a60414d076b5 patch] to the trunk that stopped Gecko's existing behavior of preserving execution order, making script-inserted script elements now execute in "as fast as possible" mode similiar to IE/Webkit. Unfortunately, the "workaround" used in IE/Webkit (described in the next section) for dealing with parallel loading and execution-order dependencies does not work in Gecko, which means presently the use-case in question is now broken in Gecko trunk/FF4 nightlies.

Moreover, Webkit recently landed a [http://trac.webkit.org/changeset/67245 patch] to the trunk that stopped Webkit's non-standard but long-held behavior (also used in the "workaround" described in the next section) of loading into cache script resources with an unrecognized "type" value, but silently not executing them. This behvaior (while hacky) is central to being able to address the use-case in question in Webkit, so at present, Webkit nightlies are now also entirely broken on the use-case (though in a different way than Gecko).

Both the Gecko change and the Webkit change are well-intentioned, as they are bringing the respective browser more in line with the HTML spec. However, what's really been demonstrated is that the HTML spec is not properly handling this use-case, and so the goal is not to address the browser issues raised with more awkward hacks, but to address the shortcomings of the spec first, and then encourage all browsers to adhere to such.

<blockquote style="background-color: #EEEEEE">
Considering Internet Explorer's readyState implementation provides a means of both parallel loading and preserving execution order can be achieved, perhaps its "readyState" property and onreadystatechange event should be included.
</blockquote>

=== Current Usage and Workarounds ===
To work around the limitation in IE/Webkit(prior to the above noted patch) of not being able to rely on script order execution for parallel loaded scripts, a "preloading" trick was developed. This trick relied on non-standard (but long-held) behavior in these browsers that a script-inserted script element with an unrecognized "type" value (such as "script/cache") would be fetched/loaded, but would not execute. This had the effect of loading the resource into cache, and then firing the "load" handlers to let the page know when the resource was completely in cache.

Assuming that the resource was served with proper caching headers, and was in fact in the cache, it could then be executed (nearly) immediately when it was the proper execution order time by re-requesting the same resource via another script-inserted script element with the proper "text/javascript" type value, pulling the resource from the cache and executing it, without another server round-trip.

Of course, the assumption of proper cache headers is a huge one, and not at all reliable. Some recent estimates by performance optimization specialists have suggested as much as 70% of scripts across the internet are not served with proper caching headers, which means that such scripts would be completely ineffective if loaded using this (or a similar) technique. The script resource would end up being loaded completely a second-time, and the "near immediate" execution would obviously be false, and thus race conditions would ensue.

It's important to note at this point that the new <link rel=prefetch> facility has been suggested as a better workaround, but it suffers the same ill-fated assumption of script cacheability. Still others have suggested "new Image().src=..." or the [http://www.phpied.com/preload-then-execute/ <object> preloading trick] suggested by Stoyan Stefanov. Again, these tricks unwisely assume cacheability, for the "preloading" trick to solve the use-case in question.

=== At Risk ===
Currently, there are several large/popular web sites which are either currently (or who intend to soon) use LABjs in such a way as to run afoul of the new Gecko and Webkit behavioral changes with LABjs failing to operate properly. It's important to note that the problems of race conditions can be subtle and hard to detect, and so merely loading up such sites and failing to observe overt failure is not sufficient.

Sites which are known to have LABjs loading techniques in place with currently broken (or susceptible to such breakage in the near future) behavior are:

* [http://twitter.com Twitter]
* [http://zappos.com Zappos]
* [http://vimeo.com Vimeo]
* [http://mefeedia.com MeFeedia]
* [http://blog.getify.com Getify Solutions blog (my blog)]
* [http://flensed.com flensed Flash+JavaScript browser shims (cross-domain Ajax, cross-browser cookies, etc)]

Rather than getting hung up in the syntax of usage in LABjs that is or is not going to break, it's best to just think of the problem this way:

Does a site need to load more than one script, at least one of which comes from a remote domain location (like a CDN), and for which among the scripts there's at least one execution-order dependency among them? If so, then that site is susceptible to the current/future breakage if the HTML spec (and browsers) do not address this use case.

A common example (in use on many sites) of such might be loading:

* jQuery from the CDN
* jQuery-UI from the CDN
* plugins and usage code in one or more local files
* Google Analytics from the Google domain

Note that the emergence of popular script frameworks and their hosting on public CDN's is leading to more and more sites loading scripts from both local and remote locations, and also to loading more files that have dependencies (rather than the practice of concat'ing all files into one file to avoid dependency issues).

Any site which fits a profile like the above, and which might currently (many do), or in the future want to, use a script loader to improve their loading performance, will fail to achieve what they want cross-browser and in a performant way, if the HTML spec (and browsers) do not address the use case.

=== Benefits ===
The benefits of addressing both behaviors directly (without "preloading" tricks and bad assumption reliance) have been implied in the above discussion, but in short are:

a) clear and simplified code for script loaders, which leads to easier use by authors of more pages, which in turn leads to better web performance (as demonstrated clearly by intelligent script loading techniques as compared to just simple <script> tags in HTML markup)

b) full access to either/both of the execution-order behaviors (as the author sees fit), regardless of browser

c) avoiding reliance on bad assumptions (like cacheability) as a sufficient way to address the use-case

=== External Discussions of this Feature ===

* <cite>[http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html W3C public-html email thread]</cite>

* <cite>[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 W3C Bug #11295]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>

* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>

* <cite>[http://hsivonen.iki.fi/script-execution/ HTML5 Script Execution Changes in Firefox 4 Beta 7]</cite>

* <cite>[http://blog.getify.com/2010/10/labjs-w3c-brief-update/ LABjs and W3C... brief update]</cite>

* <cite>[http://blog.getify.com/2010/10/ff4-script-loaders-and-order-preservation/ FF4, script loaders, and order preservation]</cite>

== Proposed Solutions ==

=== My Solution ===
The current proposal most well supported from the email discussion thread, and the one which I feel makes most sense, is described here.

The HTML spec already defines the "async" attribute for parser-inserted script tags, which when set to "true", changes their execution order behavior to be like script-inserted script-elements (in IE/Webkit), which is that they load in parallel and execute "as fast as possible" (ostensibly because the author is expressing no dependencies between multiple such "async"-marked scripts). Parser-inserted script elements without "async" (or with it set to false) behave as before and expected, which is that they load in parallel but execute in order.

However, the HTML spec does not define the "async" property (or any such behavior) for script-inserted script nodes (such as those created by a script loader). Instead, the spec implies that "async=true" like behavior is always true for such script-inserted script elements.

What is proposed is:

a) Script-inserted script elements should have (and respect the value of) an "async" property which is basically identical to the "async" attribute for parser-inserted script elements. That is, script elements with the "async" property set to "true" will behave accordingly, as will script elements with the "async" property set to false.

Essentially, the proposal is to mirror the "async" attribute behavior of parser-inserted script elements as an "async" property on script-inserted script elements. This has the benefit of using an existing facility and extending it (from current spec) in a way that is sensisble and symmetric with its current definition.
<blockquote style="background-color: #EFEFEF">
The scriptgroup or `readyState` alternate proposals allow for dependency management to be done in high-level code. The singular syncrhonized execution queue proposed here introduces artificial dependencies, undermining some of the benefits dynamic script loading provides.
</blockquote>

<blockquote style="background-color: #ccc;">
It's important to note that `async=false` scripts will load in a separate queue from `async=true` scripts. It's not that all scripts will now be forced into this insertion-order-execution queue. An author (or script loader) can chose which queue to put a script loading into based on the needs of the page and the resource. If I have a few scripts that are unrelated to each other and the main page (like Google Analytics, social sharing buttons, etc), I'll load those via `async=true`. For other scripts, where order matters for dependency sake, I'll use `async=false`. I think having both those queues available to high-level code is enough control over loading to serve the majority of use-cases pretty well.
<blockquote style="background-color: #EFEFEF">
If at any point these services begin dynamically loading `async=false` scripts of their own, they will begin blocking. This can lead to unexpected behavior of existing code as third-party libraries and services change. It would seem the specification should provide a means by which this blocking can be isolated to dependencies defined by the author and ordered execution not introduce conditions that allow unrelated libraries to affect this.
</blockquote>
</blockquote>

b) Furthermore, to aid in "feature-detection" of such new behavior, the proposal is to have the default value for the "async" property of script-inserted script elements be "true" (and of course the associated behavior thereof).

There are two major benefits to (b). One is that it provides a way to feature test such new behavior by not just looking for the existence of the "async" property on script elements, but specifically that the default value is "true" (which is opposite of what it would currently/normally be). Secondly, defaulting to "async=true" behavior for script-inserted script elements would preserve the default behavior of IE and Webkit, meaning there'd be less of a chance of breaking existing web content in either of those two browsers.

It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.

==== Proposal Amendment: Events ====
In addition to standardizing how scripts load and execute, it's also important to standardize the load and error events, and under what circumstances they fire, etc. Without reliable load/error events, the main proposal is not reliable and is thus unhelpful for the use-case.

A script-inserted script element must fire the "load" event only once, when:

a) immediately after the resource finishes loading, but before parsing/execution, AND

b) the script element loads any non-empty content (that is, it was a successful HTTP request), AND

c) the script element has either loaded from the remote location, or is loaded from the brower cache

Specifically, the script "load" event must come immediately between the script element finishing loading and the script element being parsed/executed. If the script resource successfully loads, nothing should interrupt the sequence of fininshing loading, the "load" event firing, and the script being parsed/executed.

A script-inserted script element must fire the "error" event only once, when:

a) immediately after a loading failure for the resource is detected (that is, an HTTP error received, such as 404, 500, 503, etc).

Either the "load" or "error" event, but not both, will fire, and only once, for every script-inserted script element.

NOTE: "load" and "error" events on script-inserted script elements must fire synchronously to ensure event reliability.

A case may be made for adding the "load" and "error" events as described here to parser-inserted script elements as well.

==== Processing Model ====
Script inserted script elements will have an "async" property that defaults to "true". If the author does not change the value, all such requested script loadings will be in their own "queue" and will default to "as fast as possible" execution behavior. For any script elements that the author sets "async=false", those scripts will load in a separate "queue", and will execute in insertion order only. Again, these two "queues" will operate strictly independent of each other.

==== Processing Model Details (without the event amendment) ====

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node.

When a previously-created script element node loses its parser-insertedness, if the element doesn't have the async content attribute, set the force-async flag to true and false otherwise.

When a script element node obtains the async content attribute (via setAttribute, setAttributeNode, setAttributeNS, by the fragment parser or the XSLTProcessor adding the attribute, etc.), set the force-async flag to false. (Note that calling removeAttribute("async") doesn't modify the force-async flag.)

The async IDL attribute must behave as follows:
* Upon setting, set the force-async flag to false and then reflect the async content attribute.
* Upon getting, if the force-async flag is true, return true. Otherwise, reflect the async content attribute.

In step 13. of http://www.whatwg.org/specs/web-apps/current-work/#running-a-script before the case "If the element has a src attribute" add a case:
If the script has a src attribute and the async IDL property getter returns false,
The element must be added to the queue of ordered script-inserted external scripts of the Document of the script element at the time the running a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run these steps:
# If the queue of ordered script-inserted external scripts is empty or the first script in the queue of ordered script-inserted external scripts has not been fetched yet, abort these steps.
# Execute the first script in the queue of ordered script-inserted external scripts.
# Remove the first script from queue of ordered script-inserted external scripts.
# Goto step #1.

Modify step 5 of http://www.whatwg.org/specs/web-apps/current-work/#the-end to say:
Spin the event loop until the set of scripts that will execute as soon as possible is empty and the queue of ordered script-inserted external scripts is empty.

==== Limitations ====
The two behaviors being identified solve either the case where no dependencies exist, or where a linear dependency chain exists (and which the script elements can be requested to execute in that order). It is possible that some authors have a more complex non-linear dependency chain that they would like to express. This would obviously require a much more complex API and spec change, and since that use-case has not (yet) surfaced as a particularly main-stream request, I believe it would be overengineering to try to address it with this proposed change set.

In addition, it's been duly noted that it's undesirable (and potentially confusing/problematic) to intentionally build in the inconsistency of having the "async" attribute (for parser-inserted scripts) and the "async" property (for script-inserted scripts) have different default values ("false" for the attribute, "true" for the property).

It's also been a point of discussion whether or not such a spec change has enough "carrot" to entice the browser vendors (namely IE and Webkit) to implement the behavior. Moreover, there's been some concern that if the default value for the "async" property were made to be "false" (like the attribute) to be more consistent and conservative, then it would possibly give the perception to IE and Webkit of "losing" some performance to cut out their default "as fast as possible" behavior.

=== Alternate Proposals ===
One early proposal on the email list was to introduce an entirely new property like "ordered" which an author could add to a script-inserted script element to instruct the browser to put it into the queue of execution-order-preserving script loadings. While such a property would address the use case, it introduces another property and thus more complicates the issue. It also fails to address the current spec inconsistency (which is confusing to new comers) that "async" is not a present/respected property in mirror of the attribute of the same name.

Another suggestion was a "waitFor" property that would be added to script elements and would specify a list of one or more DOM id's of other script elements that the current script should "wait for" in terms of execution. Again, this would solve the use case, but in a more complicated way, and there are concerns that it would be too confusing for the normal use-case.

Several suggestions have come in the form of creating explicit "preloading" (similar to <link rel=prefetch>), but as described above, "preloading" to solve this use case is a non-ideal hack and highly susceptible to breakage if the script fails to be sent with proper caching headers.

It's also been suggested that since this type of behavior is somewhat complicated, it may be better to intentionally obfuscate or complicate any such facility in the HTML, so as to make the barrier-to-entry rather high and force users to know what they are doing before doing it.

It's been suggested that "defer" already preserves execution order. However, "defer" is only defined for parser-inserted scripts, and thus is not applicable to the use-case in question from an on-demand point of view. Also, "defer" scripts explicitly way for DOMContentLoaded, even if they're ready to execute sooner. So this is less than desired.

Yet another proposal is a "document.executeScripts()" API, where an author can specify multiple sets of scripts that can load in parallel and it will enforce their execution order. A variation on that same idea was to use the "importScripts" from the Web Workers spec, however "importScripts" is synchronous (undesirable performance wise, obviously). The main downside (besides extra API complication) to "document.executeScripts()" is that there seem to be quite a few script execution properties/behaviors (including "document.currentScript" and charset override) which would have to be duplicated into this API facility.

==== "Script Group" element ====
One recent alternate proposal bears some special consideration, as it seems like it might be a decent option (although certainly more of a radical change for the spec and for browsers to implement). But it has the appearance of being pretty straightforward and semantic for authors to use, perhaps even more so than using "async".

The proposal is to create a new HTML element, called perhaps <scriptGroup>, <collection>, etc. Specifically, this element must be able to be inserted wherever a <script> element can currently be inserted. The "script group" element is intended to signify that all script elements added to it must perserve insertion execution order. This element wouldn't have much (but still some, explained in a moment) meaning in a parser-inserted context, since parser-inserted scripts already preserve order among themselves.

An advantage of the "script group" element would be to give a direct and easy way to attach event listeners ("load" and "error") to the entire group, rather than having to internally track events for each element if all you care about is the final "load" event, for instance. In the case of event handling, the "script group" element would have perhaps some benefit even in parser-inserted (markup) context.

The element would need to have an "id" property, and possibly attributes for "load" and "error" events.

A variation on how to look at this proposal is that a "script group" element could have an attribute/property on it (perhaps called "ordered") which would allow the group to either be order preserved or not. This would make the "script group" element much more useful in the parser-inserted context, as it would sort of be a shortcut to setting "async=true" on all the child script elements.

The "script group" element might look like this:

<scriptGroup id="group1">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

Or, with the "ordered" attribute to explicitly control ordering behavior for the group:

<scriptGroup id="group1" ordered="true">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

<scriptGroup id="group2" ordered="false" onload="alldone();">
<script src="baz.js"></script>
<script src="far.js"></script>
<script src="zab.js"></script>
</scriptGroup>

While the "script group" element is definitely more complicated to define and implement, it does have some semantic advantages for authors, and it also would significantly reduce the internal complexity of script loaders like LABjs. It would give authors (either directly or through script loaders) the flexibility to group scripts together into one of the two aforementioned behaviors (execution "as fast as possible" or "in insertion order"), and to easily access both behaviors in the same page.

==== Explicit support for "text/cache" MIME type behavior ====
Yet another alternate proposal has been suggested in the [[Talk:Dynamic_Script_Execution_Order]] thread.

Essentially, the proposal is that <script> tags directly support being declared with a `type` value of "text/cache". The behavior would be that the script resource is fetched, as the load events fired, as normal, but that the script itself would not be executed. Then later, at the desired time, the script in that element could be executed by changing the `type` value from "text/cache" to "text/javascript".

The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.
<blockquote style="background-color:#eee">
And does the onload event fire again after the script executes? <br/>
Or only when it's loaded? <br/>
Both seem to violate current `onload` semantics.
[[User:Serverherder|Serverherder]] 20:27, 15 December 2010 (UTC)

<blockquote style="background-color:#ccc">
As far as I'm concerned, I think the "load" event should happen immediately after a script loads, but before it executes, as I spell out in the [[Dynamic_Script_Execution_Order#Proposal_Amendment:_Events|Events proposal ammendment section]]. [[User:Getify|Getify]] 20:33, 15 December 2010 (UTC)
</blockquote>

</blockquote>

==== readyState "preloading" ====
Per the suggestion/comment added to the above [[Dynamic_Script_Execution_Order#Current_Limitations|Current Limitations]] section, it's been suggested that IE's current behavior with respect to the `readyState` property can adequately serve the use-case in question. This alternate proposal is very similar in spirit to the [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|previous section on explicit support for "text/cache"]] mime-type value.

The idea is that IE will begin fetching into the cache a script resource as soon as the `src` attribute of the dynamic script element is set. But IE will not execute the script (even if it finishes loading) until the script element is added to the DOM. However, the `readyState` property of the element, combined with the `onreadystatechange` handler listening for changes, can detect when the script has finished loading, by receiving the "loaded" value.

In this way, a script loader could "preload" a set of scripts all in parallel, but control their execution order by delaying the appending of the element to the DOM until execution is desired.

'''Update''' [[User:Getify|Getify]] 14:10, 20 December 2010 (UTC)

[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

Specifically, in step 12 (which is about fetching a `src` URL):

<blockquote>
For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
</blockquote>

This seems to be the spec stating that browsers may do what IE's behavior on scripts does, which is to start fetching the resource once the `src` property is set, but not execute it until the script element is inserted into the DOM.

It would seem then that browsers could/should be petitioned to consider implementing this suggestion, perhaps taking the `readyState` implementation from IE as guidance. While I'm still not sure that this would be my preferred method of solving the overall use-case in discussion on this page, it would be an option for such, and it would also help other use-cases, such as those being discussed in this W3C public-html thread:

[http://lists.w3.org/Archives/Public/public-html/2010Dec/0174.html Need to: "preload" CSS and JS]

[[Category:Feature Request|Dynamic Script Execution Order]]

Dynamic Script Execution Order

2010-12-15T20:33:27Z

Getify: reply comment regarding "load" event semantics

This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.

Briefly, this issue has arisen because recent "nightlies" changes in both Mozilla Gecko and Webkit have broken the ability for script-loaders like [http://labjs.com LABjs] to be able to download scripts in parallel but ensure their execution order. As a result of the discussion, it's become apparent that both the spec for, and various current browser implementations around, dynamic script loading is incomplete in addressing this use case, and that some change needs to occur.

There is one main proposal that has surfaced from the discussions, with several other alternatives having been discussed. This page will try to distill the long email thread down and clearly present the main proposal, objections, and alternative suggestions.

Please feel free to join the discussion of this topic in the [[Talk:Dynamic_Script_Execution_Order]] area.

== Use Case Description ==
Script tags/elements can either:

a) appear in the HTML markup ("parser-inserted"), OR

b) be dynamically appended to the DOM using document.createElement() ("script-inserted")

Parser-inserted script tags, up until recent browser versions, had the undesirable performance behavior of loading and executing serially, blocking everything else while doing so. Recently, many browsers have improved the situation by loading the scripts in parallel, but still executing them in order.

On-demand (or dynamic) script loading has emerged in recent years for a variety of different reasons, most notably the performance improvements to address such concerns. It is desired by many different scenarios to be able to download scripts to a page completely independently of the loading of the rest of a page's resources, or even well after a page has finished loading ("on-demand").

Recent additions to HTML spec such as "defer" and "async" were intended to address the use-case for parser-inserted script elements, but their behaviors have been unhelpful for the on-demand loading use-case (script-inserted script elements).

Thus, script loaders (like [http://labjs.com LABjs]) were developed to give page authors an easy way to specify one or more scripts to load (regardless of when in the life-time of the page that loading is requested), and for as many of them as possible to load in parallel, and for those scripts to be loadable from any local or remote domain location, and for the script loader to be able to control the execution order (if the usage of the script loader's API expresses the need to) to preserve dependencies between the scripts.

Sometimes, dynamic script loading is used to load totally independent scripts, and thus "as fast as possible" execution is desired. Other times (and possibly more frequently), multiple scripts are loaded with some dependencies among them, requiring them to execute in a certain order.

What is needed is some facility by which a script loader can express that dynamic script loading either does or does not need execution order preserved among the queue of requested script loadings.

=== Current Limitations ===
Unfortunately, browser behavior around script-inserted script elements and their loading and execution behavior is splintered. There are, at present, two main camps of behavior:

a) in IE and Webkit (including Chrome), the default behavior for script-inserted script elements is for them all to execute in "as fast as possible" mode, meaning there's no guarantee about ordering. This effectively makes on-demand (dynamic) script loading impossible to work in parallel-mode if the resources in question have dependencies -- the only straight-forward way to handle things is to load each file and execute, serially, losing the parallel loading performance benefits.
<blockquote style="background-color: #EEEEEE">
I'm not sure if this is the case.

IE will start fetching resources without execution simply by setting the src attribute. Scripts will not execute, however, until they are added to the document. Since IE supports the readyState attribute and readystatechange event, it's possible to load scripts in parallel and execute them in order without resorting to invalid type attribute hack-ery.

<pre style="background-color:white" lang="javascript">
script= document.createElement("SCRIPT");
script.onreadystatechange= function(){
if(this.readyState == 'loaded')
/*
Network fetch is now complete, following
triggers synchronous execution.
*/
document.body.appendChild(this);
else if(this.readyState == "complete")
this.onreadystatechange= null;
}
script.src= "foo.js";
/* Network fetching begins now */
</pre>
</blockquote>

<blockquote style="background-color: #ccc">
I've experimented with such things heavily in the past, and I'm fairly suspicious that this is not reliable across various versions of IE (6-9), nor does it work reliably the same depending on if an element is already in the browser cache or not. I'm not 100% certain that what you suggest is flawed, but I have a strong hunch that it can be shown to have some holes in it for IE loading. I will try to create some test cases to prove or disprove.
<blockquote style="background-color: #EEEEEE">
When loading a script that is in the cache, IE requires the event handler be installed prior to setting the `src` attribute. Otherwise the element's transition to the "loaded" state will be missed. IE routinely "skips" ready state transitions when cached scripts are immediately inserted into the DOM so suspicion is understandable; however, delayed insertion works around this "problem". The script above has been tested in IE6-8 with scripts in a variety of caching states and found to work correctly.
</blockquote>

Moreover, you're suggesting something that is AFAIK only IE right now, and definitely appears to not be standardized. In the same way that I'm hesitant to continue pinning loading behavior on hacks like the invalid type attribute value, I wouldn't want to approach loading with this technique (even if it were proven reliable on all IE's under all caching circumstances) unless it was a serious proposal to the W3C to have this technique be the new standard (as opposed to the current proposal, as implemented by Mozilla and Webkit now).
<blockquote style="background-color: #EEEEEE">
I think you're right: Only IE impelements this event and property on script elements. The readystatechange event, however, is widely understood due to the XmlHttpRequest implementation and `readyState` property has been added to the `document` in WebKit, Mozilla and IE.
</blockquote>

That having been said, I think this is at least a viable candidate for "Alternate Proposals" and deserves to be listed as such. As always, I welcome input from the community on all the ideas presented here, including this one. But, since the main proposal (async=false) is already being implemented by at least two major browsers, I'm not sure if the tide will be changed or not.

</blockquote>

<blockquote style="background-color:#ddd;">
Also, the suggestion of handling the "preload" and deferred execution via the script tag's `readyState` property is very similar in spirit to the suggestion that was made to explicitly support [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|preloading into cache without execution]]. As I said, either of those two approaches might work, but they both put more of the onus of complexity in managing multiple dependencies on the high-level code (author, script loader, etc). I'm more in favor of this functionality being explicitly built-in natively into the queues. As always, I welcome comments to any side of this discussion.

[[User:Getify|Getify]] 18:35, 15 December 2010 (UTC)
</blockquote>

b) in Gecko and Opera, the default behavior for script-inserted script elements is for them all to load in parallel, but execute serially in insertion order. Technically, this makes it impossible to dynamically load independent script elements and have them execute in "as fast as possible" mode.

As described above, both behaviors are desirable under different circumstances, but each of the two camps provides only one behavior, and no way to straightforwardly achieve the other. This obviously creates a big nightmare interoperability-wise when trying to provide a general script loader cross-browser.

Since it is observed that the behavior in (a) is more detrimental (race-condition wise) for the case where dependencies exist, script loaders like LABjs had to find some way around this problem while still attempting the best possible parallel loading performance. However, the trick used is hacky and not completely reliable -- yet it is the best way to solve the use-case in <s>IE and </s>Webkit.

For Gecko/Opera, the concession was just (silently) made that the lesser-common use case of "as fast as possible" wasn't possible, but degraded fine to "insertion order execution", while keeping the parallel loading benefits.

<blockquote style="background-color: #EEEEEE">
Gecko's strict execution order creates dependencies between scripts which are unrelated and prevents the ability mitigate the impact of server outages / network latency. This is exacerbated by the fact that Gecko, unlike IE and WebKit, provides no mechanism to <b>remove</b> scripts from the execution queue.

Consider the case where JSONP is used to provide auto-completion. The user types "hello" and the JSONP request is made; however, the "currently" loading script is out-of-date as soon as the user modifies his search to "hello world". Gecko's algorithm requires the out-of-date request load and execute before the second request.
</blockquote>

Recently, Gecko landed a [http://hg.mozilla.org/mozilla-central/rev/a60414d076b5 patch] to the trunk that stopped Gecko's existing behavior of preserving execution order, making script-inserted script elements now execute in "as fast as possible" mode similiar to IE/Webkit. Unfortunately, the "workaround" used in IE/Webkit (described in the next section) for dealing with parallel loading and execution-order dependencies does not work in Gecko, which means presently the use-case in question is now broken in Gecko trunk/FF4 nightlies.

Moreover, Webkit recently landed a [http://trac.webkit.org/changeset/67245 patch] to the trunk that stopped Webkit's non-standard but long-held behavior (also used in the "workaround" described in the next section) of loading into cache script resources with an unrecognized "type" value, but silently not executing them. This behvaior (while hacky) is central to being able to address the use-case in question in Webkit, so at present, Webkit nightlies are now also entirely broken on the use-case (though in a different way than Gecko).

Both the Gecko change and the Webkit change are well-intentioned, as they are bringing the respective browser more in line with the HTML spec. However, what's really been demonstrated is that the HTML spec is not properly handling this use-case, and so the goal is not to address the browser issues raised with more awkward hacks, but to address the shortcomings of the spec first, and then encourage all browsers to adhere to such.

<blockquote style="background-color: #EEEEEE">
Considering Internet Explorer's readyState implementation provides a means of both parallel loading and preserving execution order can be achieved, perhaps its "readyState" property and onreadystatechange event should be included.
</blockquote>

=== Current Usage and Workarounds ===
To work around the limitation in IE/Webkit(prior to the above noted patch) of not being able to rely on script order execution for parallel loaded scripts, a "preloading" trick was developed. This trick relied on non-standard (but long-held) behavior in these browsers that a script-inserted script element with an unrecognized "type" value (such as "script/cache") would be fetched/loaded, but would not execute. This had the effect of loading the resource into cache, and then firing the "load" handlers to let the page know when the resource was completely in cache.

Assuming that the resource was served with proper caching headers, and was in fact in the cache, it could then be executed (nearly) immediately when it was the proper execution order time by re-requesting the same resource via another script-inserted script element with the proper "text/javascript" type value, pulling the resource from the cache and executing it, without another server round-trip.

Of course, the assumption of proper cache headers is a huge one, and not at all reliable. Some recent estimates by performance optimization specialists have suggested as much as 70% of scripts across the internet are not served with proper caching headers, which means that such scripts would be completely ineffective if loaded using this (or a similar) technique. The script resource would end up being loaded completely a second-time, and the "near immediate" execution would obviously be false, and thus race conditions would ensue.

It's important to note at this point that the new <link rel=prefetch> facility has been suggested as a better workaround, but it suffers the same ill-fated assumption of script cacheability. Still others have suggested "new Image().src=..." or the [http://www.phpied.com/preload-then-execute/ <object> preloading trick] suggested by Stoyan Stefanov. Again, these tricks unwisely assume cacheability, for the "preloading" trick to solve the use-case in question.

=== At Risk ===
Currently, there are several large/popular web sites which are either currently (or who intend to soon) use LABjs in such a way as to run afoul of the new Gecko and Webkit behavioral changes with LABjs failing to operate properly. It's important to note that the problems of race conditions can be subtle and hard to detect, and so merely loading up such sites and failing to observe overt failure is not sufficient.

Sites which are known to have LABjs loading techniques in place with currently broken (or susceptible to such breakage in the near future) behavior are:

* [http://twitter.com Twitter]
* [http://zappos.com Zappos]
* [http://vimeo.com Vimeo]
* [http://mefeedia.com MeFeedia]
* [http://blog.getify.com Getify Solutions blog (my blog)]
* [http://flensed.com flensed Flash+JavaScript browser shims (cross-domain Ajax, cross-browser cookies, etc)]

Rather than getting hung up in the syntax of usage in LABjs that is or is not going to break, it's best to just think of the problem this way:

Does a site need to load more than one script, at least one of which comes from a remote domain location (like a CDN), and for which among the scripts there's at least one execution-order dependency among them? If so, then that site is susceptible to the current/future breakage if the HTML spec (and browsers) do not address this use case.

A common example (in use on many sites) of such might be loading:

* jQuery from the CDN
* jQuery-UI from the CDN
* plugins and usage code in one or more local files
* Google Analytics from the Google domain

Note that the emergence of popular script frameworks and their hosting on public CDN's is leading to more and more sites loading scripts from both local and remote locations, and also to loading more files that have dependencies (rather than the practice of concat'ing all files into one file to avoid dependency issues).

Any site which fits a profile like the above, and which might currently (many do), or in the future want to, use a script loader to improve their loading performance, will fail to achieve what they want cross-browser and in a performant way, if the HTML spec (and browsers) do not address the use case.

=== Benefits ===
The benefits of addressing both behaviors directly (without "preloading" tricks and bad assumption reliance) have been implied in the above discussion, but in short are:

a) clear and simplified code for script loaders, which leads to easier use by authors of more pages, which in turn leads to better web performance (as demonstrated clearly by intelligent script loading techniques as compared to just simple <script> tags in HTML markup)

b) full access to either/both of the execution-order behaviors (as the author sees fit), regardless of browser

c) avoiding reliance on bad assumptions (like cacheability) as a sufficient way to address the use-case

=== External Discussions of this Feature ===

* <cite>[http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html W3C public-html email thread]</cite>

* <cite>[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 W3C Bug #11295]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>

* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>

* <cite>[http://hsivonen.iki.fi/script-execution/ HTML5 Script Execution Changes in Firefox 4 Beta 7]</cite>

* <cite>[http://blog.getify.com/2010/10/labjs-w3c-brief-update/ LABjs and W3C... brief update]</cite>

* <cite>[http://blog.getify.com/2010/10/ff4-script-loaders-and-order-preservation/ FF4, script loaders, and order preservation]</cite>

== Proposed Solutions ==

=== My Solution ===
The current proposal most well supported from the email discussion thread, and the one which I feel makes most sense, is described here.

The HTML spec already defines the "async" attribute for parser-inserted script tags, which when set to "true", changes their execution order behavior to be like script-inserted script-elements (in IE/Webkit), which is that they load in parallel and execute "as fast as possible" (ostensibly because the author is expressing no dependencies between multiple such "async"-marked scripts). Parser-inserted script elements without "async" (or with it set to false) behave as before and expected, which is that they load in parallel but execute in order.

However, the HTML spec does not define the "async" property (or any such behavior) for script-inserted script nodes (such as those created by a script loader). Instead, the spec implies that "async=true" like behavior is always true for such script-inserted script elements.

What is proposed is:

a) Script-inserted script elements should have (and respect the value of) an "async" property which is basically identical to the "async" attribute for parser-inserted script elements. That is, script elements with the "async" property set to "true" will behave accordingly, as will script elements with the "async" property set to false.

Essentially, the proposal is to mirror the "async" attribute behavior of parser-inserted script elements as an "async" property on script-inserted script elements. This has the benefit of using an existing facility and extending it (from current spec) in a way that is sensisble and symmetric with its current definition.
<blockquote style="background-color: #EFEFEF">
The scriptgroup or `readyState` alternate proposals allow for dependency management to be done in high-level code. The singular syncrhonized execution queue proposed here introduces artificial dependencies, undermining some of the benefits dynamic script loading provides.
</blockquote>

<blockquote style="background-color: #ccc;">
It's important to note that `async=false` scripts will load in a separate queue from `async=true` scripts. It's not that all scripts will now be forced into this insertion-order-execution queue. An author (or script loader) can chose which queue to put a script loading into based on the needs of the page and the resource. If I have a few scripts that are unrelated to each other and the main page (like Google Analytics, social sharing buttons, etc), I'll load those via `async=true`. For other scripts, where order matters for dependency sake, I'll use `async=false`. I think having both those queues available to high-level code is enough control over loading to serve the majority of use-cases pretty well.
<blockquote style="background-color: #EFEFEF">
If at any point these services begin dynamically loading `async=false` scripts of their own, they will begin blocking. This can lead to unexpected behavior of existing code as third-party libraries and services change. It would seem the specification should provide a means by which this blocking can be isolated to dependencies defined by the author and ordered execution not introduce conditions that allow unrelated libraries to affect this.
</blockquote>
</blockquote>

b) Furthermore, to aid in "feature-detection" of such new behavior, the proposal is to have the default value for the "async" property of script-inserted script elements be "true" (and of course the associated behavior thereof).

There are two major benefits to (b). One is that it provides a way to feature test such new behavior by not just looking for the existence of the "async" property on script elements, but specifically that the default value is "true" (which is opposite of what it would currently/normally be). Secondly, defaulting to "async=true" behavior for script-inserted script elements would preserve the default behavior of IE and Webkit, meaning there'd be less of a chance of breaking existing web content in either of those two browsers.

It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.

==== Proposal Amendment: Events ====
In addition to standardizing how scripts load and execute, it's also important to standardize the load and error events, and under what circumstances they fire, etc. Without reliable load/error events, the main proposal is not reliable and is thus unhelpful for the use-case.

A script-inserted script element must fire the "load" event only once, when:

a) immediately after the resource finishes loading, but before parsing/execution, AND

b) the script element loads any non-empty content (that is, it was a successful HTTP request), AND

c) the script element has either loaded from the remote location, or is loaded from the brower cache

Specifically, the script "load" event must come immediately between the script element finishing loading and the script element being parsed/executed. If the script resource successfully loads, nothing should interrupt the sequence of fininshing loading, the "load" event firing, and the script being parsed/executed.

A script-inserted script element must fire the "error" event only once, when:

a) immediately after a loading failure for the resource is detected (that is, an HTTP error received, such as 404, 500, 503, etc).

Either the "load" or "error" event, but not both, will fire, and only once, for every script-inserted script element.

NOTE: "load" and "error" events on script-inserted script elements must fire synchronously to ensure event reliability.

A case may be made for adding the "load" and "error" events as described here to parser-inserted script elements as well.

==== Processing Model ====
Script inserted script elements will have an "async" property that defaults to "true". If the author does not change the value, all such requested script loadings will be in their own "queue" and will default to "as fast as possible" execution behavior. For any script elements that the author sets "async=false", those scripts will load in a separate "queue", and will execute in insertion order only. Again, these two "queues" will operate strictly independent of each other.

==== Processing Model Details (without the event amendment) ====

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node.

When a previously-created script element node loses its parser-insertedness, if the element doesn't have the async content attribute, set the force-async flag to true and false otherwise.

When a script element node obtains the async content attribute (via setAttribute, setAttributeNode, setAttributeNS, by the fragment parser or the XSLTProcessor adding the attribute, etc.), set the force-async flag to false. (Note that calling removeAttribute("async") doesn't modify the force-async flag.)

The async IDL attribute must behave as follows:
* Upon setting, set the force-async flag to false and then reflect the async content attribute.
* Upon getting, if the force-async flag is true, return true. Otherwise, reflect the async content attribute.

In step 13. of http://www.whatwg.org/specs/web-apps/current-work/#running-a-script before the case "If the element has a src attribute" add a case:
If the script has a src attribute and the async IDL property getter returns false,
The element must be added to the queue of ordered script-inserted external scripts of the Document of the script element at the time the running a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run these steps:
# If the queue of ordered script-inserted external scripts is empty or the first script in the queue of ordered script-inserted external scripts has not been fetched yet, abort these steps.
# Execute the first script in the queue of ordered script-inserted external scripts.
# Remove the first script from queue of ordered script-inserted external scripts.
# Goto step #1.

Modify step 5 of http://www.whatwg.org/specs/web-apps/current-work/#the-end to say:
Spin the event loop until the set of scripts that will execute as soon as possible is empty and the queue of ordered script-inserted external scripts is empty.

==== Limitations ====
The two behaviors being identified solve either the case where no dependencies exist, or where a linear dependency chain exists (and which the script elements can be requested to execute in that order). It is possible that some authors have a more complex non-linear dependency chain that they would like to express. This would obviously require a much more complex API and spec change, and since that use-case has not (yet) surfaced as a particularly main-stream request, I believe it would be overengineering to try to address it with this proposed change set.

In addition, it's been duly noted that it's undesirable (and potentially confusing/problematic) to intentionally build in the inconsistency of having the "async" attribute (for parser-inserted scripts) and the "async" property (for script-inserted scripts) have different default values ("false" for the attribute, "true" for the property).

It's also been a point of discussion whether or not such a spec change has enough "carrot" to entice the browser vendors (namely IE and Webkit) to implement the behavior. Moreover, there's been some concern that if the default value for the "async" property were made to be "false" (like the attribute) to be more consistent and conservative, then it would possibly give the perception to IE and Webkit of "losing" some performance to cut out their default "as fast as possible" behavior.

=== Alternate Proposals ===
One early proposal on the email list was to introduce an entirely new property like "ordered" which an author could add to a script-inserted script element to instruct the browser to put it into the queue of execution-order-preserving script loadings. While such a property would address the use case, it introduces another property and thus more complicates the issue. It also fails to address the current spec inconsistency (which is confusing to new comers) that "async" is not a present/respected property in mirror of the attribute of the same name.

Another suggestion was a "waitFor" property that would be added to script elements and would specify a list of one or more DOM id's of other script elements that the current script should "wait for" in terms of execution. Again, this would solve the use case, but in a more complicated way, and there are concerns that it would be too confusing for the normal use-case.

Several suggestions have come in the form of creating explicit "preloading" (similar to <link rel=prefetch>), but as described above, "preloading" to solve this use case is a non-ideal hack and highly susceptible to breakage if the script fails to be sent with proper caching headers.

It's also been suggested that since this type of behavior is somewhat complicated, it may be better to intentionally obfuscate or complicate any such facility in the HTML, so as to make the barrier-to-entry rather high and force users to know what they are doing before doing it.

It's been suggested that "defer" already preserves execution order. However, "defer" is only defined for parser-inserted scripts, and thus is not applicable to the use-case in question from an on-demand point of view. Also, "defer" scripts explicitly way for DOMContentLoaded, even if they're ready to execute sooner. So this is less than desired.

Yet another proposal is a "document.executeScripts()" API, where an author can specify multiple sets of scripts that can load in parallel and it will enforce their execution order. A variation on that same idea was to use the "importScripts" from the Web Workers spec, however "importScripts" is synchronous (undesirable performance wise, obviously). The main downside (besides extra API complication) to "document.executeScripts()" is that there seem to be quite a few script execution properties/behaviors (including "document.currentScript" and charset override) which would have to be duplicated into this API facility.

==== "Script Group" element ====
One recent alternate proposal bears some special consideration, as it seems like it might be a decent option (although certainly more of a radical change for the spec and for browsers to implement). But it has the appearance of being pretty straightforward and semantic for authors to use, perhaps even more so than using "async".

The proposal is to create a new HTML element, called perhaps <scriptGroup>, <collection>, etc. Specifically, this element must be able to be inserted wherever a <script> element can currently be inserted. The "script group" element is intended to signify that all script elements added to it must perserve insertion execution order. This element wouldn't have much (but still some, explained in a moment) meaning in a parser-inserted context, since parser-inserted scripts already preserve order among themselves.

An advantage of the "script group" element would be to give a direct and easy way to attach event listeners ("load" and "error") to the entire group, rather than having to internally track events for each element if all you care about is the final "load" event, for instance. In the case of event handling, the "script group" element would have perhaps some benefit even in parser-inserted (markup) context.

The element would need to have an "id" property, and possibly attributes for "load" and "error" events.

A variation on how to look at this proposal is that a "script group" element could have an attribute/property on it (perhaps called "ordered") which would allow the group to either be order preserved or not. This would make the "script group" element much more useful in the parser-inserted context, as it would sort of be a shortcut to setting "async=true" on all the child script elements.

The "script group" element might look like this:

<scriptGroup id="group1">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

Or, with the "ordered" attribute to explicitly control ordering behavior for the group:

<scriptGroup id="group1" ordered="true">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

<scriptGroup id="group2" ordered="false" onload="alldone();">
<script src="baz.js"></script>
<script src="far.js"></script>
<script src="zab.js"></script>
</scriptGroup>

While the "script group" element is definitely more complicated to define and implement, it does have some semantic advantages for authors, and it also would significantly reduce the internal complexity of script loaders like LABjs. It would give authors (either directly or through script loaders) the flexibility to group scripts together into one of the two aforementioned behaviors (execution "as fast as possible" or "in insertion order"), and to easily access both behaviors in the same page.

==== Explicit support for "text/cache" MIME type behavior ====
Yet another alternate proposal has been suggested in the [[Talk:Dynamic_Script_Execution_Order]] thread.

Essentially, the proposal is that <script> tags directly support being declared with a `type` value of "text/cache". The behavior would be that the script resource is fetched, as the load events fired, as normal, but that the script itself would not be executed. Then later, at the desired time, the script in that element could be executed by changing the `type` value from "text/cache" to "text/javascript".

The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.
<blockquote style="background-color:#eee">
And does the onload event fire again after the script executes? <br/>
Or only when it's loaded? <br/>
Both seem to violate current `onload` semantics.
[[User:Serverherder|Serverherder]] 20:27, 15 December 2010 (UTC)

<blockquote style="background-color:#ccc">
As far as I'm concerned, I think the "load" event should happen immediately after a script loads, but before it executes, as I spell out in the [[Dynamic_Script_Execution_Order#Proposal_Amendment:_Events|Events proposal ammendment section]]. [[User:Getify|Getify]] 20:33, 15 December 2010 (UTC)
</blockquote>

</blockquote>

==== readyState "preloading" ====
Per the suggestion/comment added to the above [[Dynamic_Script_Execution_Order#Current_Limitations|Current Limitations]] section, it's been suggested that IE's current behavior with respect to the `readyState` property can adequately serve the use-case in question. This alternate proposal is very similar in spirit to the [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|previous section on explicit support for "text/cache"]] mime-type value.

The idea is that IE will begin fetching into the cache a script resource as soon as the `src` attribute of the dynamic script element is set. But IE will not execute the script (even if it finishes loading) until the script element is added to the DOM. However, the `readyState` property of the element, combined with the `onreadystatechange` handler listening for changes, can detect when the script has finished loading, by receiving the "loaded" value.

In this way, a script loader could "preload" a set of scripts all in parallel, but control their execution order by delaying the appending of the element to the DOM until execution is desired.

[[Category:Feature Request|Dynamic Script Execution Order]]

Talk:Dynamic Script Execution Order

2010-12-15T20:06:19Z

Getify: more response regarding multiple loading queues

Dynamic Script Execution Order

2010-12-15T18:38:41Z

Getify: added note about relation between two sections

This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.

Briefly, this issue has arisen because recent "nightlies" changes in both Mozilla Gecko and Webkit have broken the ability for script-loaders like [http://labjs.com LABjs] to be able to download scripts in parallel but ensure their execution order. As a result of the discussion, it's become apparent that both the spec for, and various current browser implementations around, dynamic script loading is incomplete in addressing this use case, and that some change needs to occur.

There is one main proposal that has surfaced from the discussions, with several other alternatives having been discussed. This page will try to distill the long email thread down and clearly present the main proposal, objections, and alternative suggestions.

Please feel free to join the discussion of this topic in the [[Talk:Dynamic_Script_Execution_Order]] area.

== Use Case Description ==
Script tags/elements can either:

a) appear in the HTML markup ("parser-inserted"), OR

b) be dynamically appended to the DOM using document.createElement() ("script-inserted")

Parser-inserted script tags, up until recent browser versions, had the undesirable performance behavior of loading and executing serially, blocking everything else while doing so. Recently, many browsers have improved the situation by loading the scripts in parallel, but still executing them in order.

On-demand (or dynamic) script loading has emerged in recent years for a variety of different reasons, most notably the performance improvements to address such concerns. It is desired by many different scenarios to be able to download scripts to a page completely independently of the loading of the rest of a page's resources, or even well after a page has finished loading ("on-demand").

Recent additions to HTML spec such as "defer" and "async" were intended to address the use-case for parser-inserted script elements, but their behaviors have been unhelpful for the on-demand loading use-case (script-inserted script elements).

Thus, script loaders (like [http://labjs.com LABjs]) were developed to give page authors an easy way to specify one or more scripts to load (regardless of when in the life-time of the page that loading is requested), and for as many of them as possible to load in parallel, and for those scripts to be loadable from any local or remote domain location, and for the script loader to be able to control the execution order (if the usage of the script loader's API expresses the need to) to preserve dependencies between the scripts.

Sometimes, dynamic script loading is used to load totally independent scripts, and thus "as fast as possible" execution is desired. Other times (and possibly more frequently), multiple scripts are loaded with some dependencies among them, requiring them to execute in a certain order.

What is needed is some facility by which a script loader can express that dynamic script loading either does or does not need execution order preserved among the queue of requested script loadings.

=== Current Limitations ===
Unfortunately, browser behavior around script-inserted script elements and their loading and execution behavior is splintered. There are, at present, two main camps of behavior:

a) in IE and Webkit (including Chrome), the default behavior for script-inserted script elements is for them all to execute in "as fast as possible" mode, meaning there's no guarantee about ordering. This effectively makes on-demand (dynamic) script loading impossible to work in parallel-mode if the resources in question have dependencies -- the only straight-forward way to handle things is to load each file and execute, serially, losing the parallel loading performance benefits.
<blockquote style="background-color: #EEEEEE">
I'm not sure if this is the case.

IE will start fetching resources without execution simply by setting the src attribute. Scripts will not execute, however, until they are added to the document. Since IE supports the readyState attribute and readystatechange event, it's possible to load scripts in parallel and execute them in order without resorting to invalid type attribute hack-ery.

<pre style="background-color:white" lang="javascript">
script= document.createElement("SCRIPT");
script.onreadystatechange= function(){
if(this.readyState == 'loaded')
/*
Network fetch is now complete, following
triggers synchronous execution.
*/
document.body.appendChild(this);
else if(this.readyState == "complete")
this.onreadystatechange= null;
}
script.src= "foo.js";
/* Network fetching begins now */
</pre>
</blockquote>

<blockquote style="background-color: #ccc">
I've experimented with such things heavily in the past, and I'm fairly suspicious that this is not reliable across various versions of IE (6-9), nor does it work reliably the same depending on if an element is already in the browser cache or not. I'm not 100% certain that what you suggest is flawed, but I have a strong hunch that it can be shown to have some holes in it for IE loading. I will try to create some test cases to prove or disprove.
<blockquote style="background-color: #EEEEEE">
When loading a script that is in the cache, IE requires the event handler be installed prior to setting the `src` attribute. Otherwise the element's transition to the "loaded" state will be missed. IE routinely "skips" ready state transitions when cached scripts are immediately inserted into the DOM so suspicion is understandable; however, delayed insertion works around this "problem". The script above has been tested in IE6-8 with scripts in a variety of caching states and found to work correctly.
</blockquote>

Moreover, you're suggesting something that is AFAIK only IE right now, and definitely appears to not be standardized. In the same way that I'm hesitant to continue pinning loading behavior on hacks like the invalid type attribute value, I wouldn't want to approach loading with this technique (even if it were proven reliable on all IE's under all caching circumstances) unless it was a serious proposal to the W3C to have this technique be the new standard (as opposed to the current proposal, as implemented by Mozilla and Webkit now).
<blockquote style="background-color: #EEEEEE">
I think you're right: Only IE impelements this event and property on script elements. The readystatechange event, however, is widely understood due to the XmlHttpRequest implementation and `readyState` property has been added to the `document` in WebKit, Mozilla and IE.
</blockquote>

That having been said, I think this is at least a viable candidate for "Alternate Proposals" and deserves to be listed as such. As always, I welcome input from the community on all the ideas presented here, including this one. But, since the main proposal (async=false) is already being implemented by at least two major browsers, I'm not sure if the tide will be changed or not.

</blockquote>

<blockquote style="background-color:#ddd;">
Also, the suggestion of handling the "preload" and deferred execution via the script tag's `readyState` property is very similar in spirit to the suggestion that was made to explicitly support [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|preloading into cache without execution]]. As I said, either of those two approaches might work, but they both put more of the onus of complexity in managing multiple dependencies on the high-level code (author, script loader, etc). I'm more in favor of this functionality being explicitly built-in natively into the queues. As always, I welcome comments to any side of this discussion.

[[User:Getify|Getify]] 18:35, 15 December 2010 (UTC)
</blockquote>

b) in Gecko and Opera, the default behavior for script-inserted script elements is for them all to load in parallel, but execute serially in insertion order. Technically, this makes it impossible to dynamically load independent script elements and have them execute in "as fast as possible" mode.

As described above, both behaviors are desirable under different circumstances, but each of the two camps provides only one behavior, and no way to straightforwardly achieve the other. This obviously creates a big nightmare interoperability-wise when trying to provide a general script loader cross-browser.

Since it is observed that the behavior in (a) is more detrimental (race-condition wise) for the case where dependencies exist, script loaders like LABjs had to find some way around this problem while still attempting the best possible parallel loading performance. However, the trick used is hacky and not completely reliable -- yet it is the best way to solve the use-case in <s>IE and </s>Webkit.

For Gecko/Opera, the concession was just (silently) made that the lesser-common use case of "as fast as possible" wasn't possible, but degraded fine to "insertion order execution", while keeping the parallel loading benefits.

<blockquote style="background-color: #EEEEEE">
Gecko's strict execution order creates dependencies between scripts which are unrelated and prevents the ability mitigate the impact of server outages / network latency. This is exacerbated by the fact that Gecko, unlike IE and WebKit, provides no mechanism to <b>remove</b> scripts from the execution queue.

Consider the case where JSONP is used to provide auto-completion. The user types "hello" and the JSONP request is made; however, the "currently" loading script is out-of-date as soon as the user modifies his search to "hello world". Gecko's algorithm requires the out-of-date request load and execute before the second request.
</blockquote>

Recently, Gecko landed a [http://hg.mozilla.org/mozilla-central/rev/a60414d076b5 patch] to the trunk that stopped Gecko's existing behavior of preserving execution order, making script-inserted script elements now execute in "as fast as possible" mode similiar to IE/Webkit. Unfortunately, the "workaround" used in IE/Webkit (described in the next section) for dealing with parallel loading and execution-order dependencies does not work in Gecko, which means presently the use-case in question is now broken in Gecko trunk/FF4 nightlies.

Moreover, Webkit recently landed a [http://trac.webkit.org/changeset/67245 patch] to the trunk that stopped Webkit's non-standard but long-held behavior (also used in the "workaround" described in the next section) of loading into cache script resources with an unrecognized "type" value, but silently not executing them. This behvaior (while hacky) is central to being able to address the use-case in question in Webkit, so at present, Webkit nightlies are now also entirely broken on the use-case (though in a different way than Gecko).

Both the Gecko change and the Webkit change are well-intentioned, as they are bringing the respective browser more in line with the HTML spec. However, what's really been demonstrated is that the HTML spec is not properly handling this use-case, and so the goal is not to address the browser issues raised with more awkward hacks, but to address the shortcomings of the spec first, and then encourage all browsers to adhere to such.

<blockquote style="background-color: #EEEEEE">
Considering Internet Explorer's readyState implementation provides a means of both parallel loading and preserving execution order can be achieved, perhaps its "readyState" property and onreadystatechange event should be included.
</blockquote>

=== Current Usage and Workarounds ===
To work around the limitation in IE/Webkit(prior to the above noted patch) of not being able to rely on script order execution for parallel loaded scripts, a "preloading" trick was developed. This trick relied on non-standard (but long-held) behavior in these browsers that a script-inserted script element with an unrecognized "type" value (such as "script/cache") would be fetched/loaded, but would not execute. This had the effect of loading the resource into cache, and then firing the "load" handlers to let the page know when the resource was completely in cache.

Assuming that the resource was served with proper caching headers, and was in fact in the cache, it could then be executed (nearly) immediately when it was the proper execution order time by re-requesting the same resource via another script-inserted script element with the proper "text/javascript" type value, pulling the resource from the cache and executing it, without another server round-trip.

Of course, the assumption of proper cache headers is a huge one, and not at all reliable. Some recent estimates by performance optimization specialists have suggested as much as 70% of scripts across the internet are not served with proper caching headers, which means that such scripts would be completely ineffective if loaded using this (or a similar) technique. The script resource would end up being loaded completely a second-time, and the "near immediate" execution would obviously be false, and thus race conditions would ensue.

It's important to note at this point that the new <link rel=prefetch> facility has been suggested as a better workaround, but it suffers the same ill-fated assumption of script cacheability. Still others have suggested "new Image().src=..." or the [http://www.phpied.com/preload-then-execute/ <object> preloading trick] suggested by Stoyan Stefanov. Again, these tricks unwisely assume cacheability, for the "preloading" trick to solve the use-case in question.

=== At Risk ===
Currently, there are several large/popular web sites which are either currently (or who intend to soon) use LABjs in such a way as to run afoul of the new Gecko and Webkit behavioral changes with LABjs failing to operate properly. It's important to note that the problems of race conditions can be subtle and hard to detect, and so merely loading up such sites and failing to observe overt failure is not sufficient.

Sites which are known to have LABjs loading techniques in place with currently broken (or susceptible to such breakage in the near future) behavior are:

* [http://twitter.com Twitter]
* [http://zappos.com Zappos]
* [http://vimeo.com Vimeo]
* [http://mefeedia.com MeFeedia]
* [http://blog.getify.com Getify Solutions blog (my blog)]
* [http://flensed.com flensed Flash+JavaScript browser shims (cross-domain Ajax, cross-browser cookies, etc)]

Rather than getting hung up in the syntax of usage in LABjs that is or is not going to break, it's best to just think of the problem this way:

Does a site need to load more than one script, at least one of which comes from a remote domain location (like a CDN), and for which among the scripts there's at least one execution-order dependency among them? If so, then that site is susceptible to the current/future breakage if the HTML spec (and browsers) do not address this use case.

A common example (in use on many sites) of such might be loading:

* jQuery from the CDN
* jQuery-UI from the CDN
* plugins and usage code in one or more local files
* Google Analytics from the Google domain

Note that the emergence of popular script frameworks and their hosting on public CDN's is leading to more and more sites loading scripts from both local and remote locations, and also to loading more files that have dependencies (rather than the practice of concat'ing all files into one file to avoid dependency issues).

Any site which fits a profile like the above, and which might currently (many do), or in the future want to, use a script loader to improve their loading performance, will fail to achieve what they want cross-browser and in a performant way, if the HTML spec (and browsers) do not address the use case.

=== Benefits ===
The benefits of addressing both behaviors directly (without "preloading" tricks and bad assumption reliance) have been implied in the above discussion, but in short are:

a) clear and simplified code for script loaders, which leads to easier use by authors of more pages, which in turn leads to better web performance (as demonstrated clearly by intelligent script loading techniques as compared to just simple <script> tags in HTML markup)

b) full access to either/both of the execution-order behaviors (as the author sees fit), regardless of browser

c) avoiding reliance on bad assumptions (like cacheability) as a sufficient way to address the use-case

=== External Discussions of this Feature ===

* <cite>[http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html W3C public-html email thread]</cite>

* <cite>[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 W3C Bug #11295]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>

* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>

* <cite>[http://hsivonen.iki.fi/script-execution/ HTML5 Script Execution Changes in Firefox 4 Beta 7]</cite>

* <cite>[http://blog.getify.com/2010/10/labjs-w3c-brief-update/ LABjs and W3C... brief update]</cite>

* <cite>[http://blog.getify.com/2010/10/ff4-script-loaders-and-order-preservation/ FF4, script loaders, and order preservation]</cite>

== Proposed Solutions ==

=== My Solution ===
The current proposal most well supported from the email discussion thread, and the one which I feel makes most sense, is described here.

The HTML spec already defines the "async" attribute for parser-inserted script tags, which when set to "true", changes their execution order behavior to be like script-inserted script-elements (in IE/Webkit), which is that they load in parallel and execute "as fast as possible" (ostensibly because the author is expressing no dependencies between multiple such "async"-marked scripts). Parser-inserted script elements without "async" (or with it set to false) behave as before and expected, which is that they load in parallel but execute in order.

However, the HTML spec does not define the "async" property (or any such behavior) for script-inserted script nodes (such as those created by a script loader). Instead, the spec implies that "async=true" like behavior is always true for such script-inserted script elements.

What is proposed is:

a) Script-inserted script elements should have (and respect the value of) an "async" property which is basically identical to the "async" attribute for parser-inserted script elements. That is, script elements with the "async" property set to "true" will behave accordingly, as will script elements with the "async" property set to false.

Essentially, the proposal is to mirror the "async" attribute behavior of parser-inserted script elements as an "async" property on script-inserted script elements. This has the benefit of using an existing facility and extending it (from current spec) in a way that is sensisble and symmetric with its current definition.
<blockquote style="background-color: #EFEFEF">
The scriptgroup or `readyState` alternate proposals allow for dependency management to be done in high-level code. The singular syncrhonized execution queue proposed here introduces artificial dependencies, undermining some of the benefits dynamic script loading provides.
</blockquote>

<blockquote style="background-color: #ccc;">
It's important to note that `async=false` scripts will load in a separate queue from `async=true` scripts. It's not that all scripts will now be forced into this insertion-order-execution queue. An author (or script loader) can chose which queue to put a script loading into based on the needs of the page and the resource. If I have a few scripts that are unrelated to each other and the main page (like Google Analytics, social sharing buttons, etc), I'll load those via `async=true`. For other scripts, where order matters for dependency sake, I'll use `async=false`. I think having both those queues available to high-level code is enough control over loading to serve the majority of use-cases pretty well.
</blockquote>

b) Furthermore, to aid in "feature-detection" of such new behavior, the proposal is to have the default value for the "async" property of script-inserted script elements be "true" (and of course the associated behavior thereof).

There are two major benefits to (b). One is that it provides a way to feature test such new behavior by not just looking for the existence of the "async" property on script elements, but specifically that the default value is "true" (which is opposite of what it would currently/normally be). Secondly, defaulting to "async=true" behavior for script-inserted script elements would preserve the default behavior of IE and Webkit, meaning there'd be less of a chance of breaking existing web content in either of those two browsers.

It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.

==== Proposal Amendment: Events ====
In addition to standardizing how scripts load and execute, it's also important to standardize the load and error events, and under what circumstances they fire, etc. Without reliable load/error events, the main proposal is not reliable and is thus unhelpful for the use-case.

A script-inserted script element must fire the "load" event only once, when:

a) immediately after the resource finishes loading, but before parsing/execution, AND

b) the script element loads any non-empty content (that is, it was a successful HTTP request), AND

c) the script element has either loaded from the remote location, or is loaded from the brower cache

Specifically, the script "load" event must come immediately between the script element finishing loading and the script element being parsed/executed. If the script resource successfully loads, nothing should interrupt the sequence of fininshing loading, the "load" event firing, and the script being parsed/executed.

A script-inserted script element must fire the "error" event only once, when:

a) immediately after a loading failure for the resource is detected (that is, an HTTP error received, such as 404, 500, 503, etc).

Either the "load" or "error" event, but not both, will fire, and only once, for every script-inserted script element.

NOTE: "load" and "error" events on script-inserted script elements must fire synchronously to ensure event reliability.

A case may be made for adding the "load" and "error" events as described here to parser-inserted script elements as well.

==== Processing Model ====
Script inserted script elements will have an "async" property that defaults to "true". If the author does not change the value, all such requested script loadings will be in their own "queue" and will default to "as fast as possible" execution behavior. For any script elements that the author sets "async=false", those scripts will load in a separate "queue", and will execute in insertion order only. Again, these two "queues" will operate strictly independent of each other.

==== Processing Model Details (without the event amendment) ====

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node.

When a previously-created script element node loses its parser-insertedness, if the element doesn't have the async content attribute, set the force-async flag to true and false otherwise.

When a script element node obtains the async content attribute (via setAttribute, setAttributeNode, setAttributeNS, by the fragment parser or the XSLTProcessor adding the attribute, etc.), set the force-async flag to false. (Note that calling removeAttribute("async") doesn't modify the force-async flag.)

The async IDL attribute must behave as follows:
* Upon setting, set the force-async flag to false and then reflect the async content attribute.
* Upon getting, if the force-async flag is true, return true. Otherwise, reflect the async content attribute.

In step 13. of http://www.whatwg.org/specs/web-apps/current-work/#running-a-script before the case "If the element has a src attribute" add a case:
If the script has a src attribute and the async IDL property getter returns false,
The element must be added to the queue of ordered script-inserted external scripts of the Document of the script element at the time the running a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run these steps:
# If the queue of ordered script-inserted external scripts is empty or the first script in the queue of ordered script-inserted external scripts has not been fetched yet, abort these steps.
# Execute the first script in the queue of ordered script-inserted external scripts.
# Remove the first script from queue of ordered script-inserted external scripts.
# Goto step #1.

Modify step 5 of http://www.whatwg.org/specs/web-apps/current-work/#the-end to say:
Spin the event loop until the set of scripts that will execute as soon as possible is empty and the queue of ordered script-inserted external scripts is empty.

==== Limitations ====
The two behaviors being identified solve either the case where no dependencies exist, or where a linear dependency chain exists (and which the script elements can be requested to execute in that order). It is possible that some authors have a more complex non-linear dependency chain that they would like to express. This would obviously require a much more complex API and spec change, and since that use-case has not (yet) surfaced as a particularly main-stream request, I believe it would be overengineering to try to address it with this proposed change set.

In addition, it's been duly noted that it's undesirable (and potentially confusing/problematic) to intentionally build in the inconsistency of having the "async" attribute (for parser-inserted scripts) and the "async" property (for script-inserted scripts) have different default values ("false" for the attribute, "true" for the property).

It's also been a point of discussion whether or not such a spec change has enough "carrot" to entice the browser vendors (namely IE and Webkit) to implement the behavior. Moreover, there's been some concern that if the default value for the "async" property were made to be "false" (like the attribute) to be more consistent and conservative, then it would possibly give the perception to IE and Webkit of "losing" some performance to cut out their default "as fast as possible" behavior.

=== Alternate Proposals ===
One early proposal on the email list was to introduce an entirely new property like "ordered" which an author could add to a script-inserted script element to instruct the browser to put it into the queue of execution-order-preserving script loadings. While such a property would address the use case, it introduces another property and thus more complicates the issue. It also fails to address the current spec inconsistency (which is confusing to new comers) that "async" is not a present/respected property in mirror of the attribute of the same name.

Another suggestion was a "waitFor" property that would be added to script elements and would specify a list of one or more DOM id's of other script elements that the current script should "wait for" in terms of execution. Again, this would solve the use case, but in a more complicated way, and there are concerns that it would be too confusing for the normal use-case.

Several suggestions have come in the form of creating explicit "preloading" (similar to <link rel=prefetch>), but as described above, "preloading" to solve this use case is a non-ideal hack and highly susceptible to breakage if the script fails to be sent with proper caching headers.

It's also been suggested that since this type of behavior is somewhat complicated, it may be better to intentionally obfuscate or complicate any such facility in the HTML, so as to make the barrier-to-entry rather high and force users to know what they are doing before doing it.

It's been suggested that "defer" already preserves execution order. However, "defer" is only defined for parser-inserted scripts, and thus is not applicable to the use-case in question from an on-demand point of view. Also, "defer" scripts explicitly way for DOMContentLoaded, even if they're ready to execute sooner. So this is less than desired.

Yet another proposal is a "document.executeScripts()" API, where an author can specify multiple sets of scripts that can load in parallel and it will enforce their execution order. A variation on that same idea was to use the "importScripts" from the Web Workers spec, however "importScripts" is synchronous (undesirable performance wise, obviously). The main downside (besides extra API complication) to "document.executeScripts()" is that there seem to be quite a few script execution properties/behaviors (including "document.currentScript" and charset override) which would have to be duplicated into this API facility.

==== "Script Group" element ====
One recent alternate proposal bears some special consideration, as it seems like it might be a decent option (although certainly more of a radical change for the spec and for browsers to implement). But it has the appearance of being pretty straightforward and semantic for authors to use, perhaps even more so than using "async".

The proposal is to create a new HTML element, called perhaps <scriptGroup>, <collection>, etc. Specifically, this element must be able to be inserted wherever a <script> element can currently be inserted. The "script group" element is intended to signify that all script elements added to it must perserve insertion execution order. This element wouldn't have much (but still some, explained in a moment) meaning in a parser-inserted context, since parser-inserted scripts already preserve order among themselves.

An advantage of the "script group" element would be to give a direct and easy way to attach event listeners ("load" and "error") to the entire group, rather than having to internally track events for each element if all you care about is the final "load" event, for instance. In the case of event handling, the "script group" element would have perhaps some benefit even in parser-inserted (markup) context.

The element would need to have an "id" property, and possibly attributes for "load" and "error" events.

A variation on how to look at this proposal is that a "script group" element could have an attribute/property on it (perhaps called "ordered") which would allow the group to either be order preserved or not. This would make the "script group" element much more useful in the parser-inserted context, as it would sort of be a shortcut to setting "async=true" on all the child script elements.

The "script group" element might look like this:

<scriptGroup id="group1">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

Or, with the "ordered" attribute to explicitly control ordering behavior for the group:

<scriptGroup id="group1" ordered="true">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

<scriptGroup id="group2" ordered="false" onload="alldone();">
<script src="baz.js"></script>
<script src="far.js"></script>
<script src="zab.js"></script>
</scriptGroup>

While the "script group" element is definitely more complicated to define and implement, it does have some semantic advantages for authors, and it also would significantly reduce the internal complexity of script loaders like LABjs. It would give authors (either directly or through script loaders) the flexibility to group scripts together into one of the two aforementioned behaviors (execution "as fast as possible" or "in insertion order"), and to easily access both behaviors in the same page.

==== Explicit support for "text/cache" MIME type behavior ====
Yet another alternate proposal has been suggested in the [[Talk:Dynamic_Script_Execution_Order]] thread.

Essentially, the proposal is that <script> tags directly support being declared with a `type` value of "text/cache". The behavior would be that the script resource is fetched, as the load events fired, as normal, but that the script itself would not be executed. Then later, at the desired time, the script in that element could be executed by changing the `type` value from "text/cache" to "text/javascript".

The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.

==== readyState "preloading" ====
Per the suggestion/comment added to the above [[Dynamic_Script_Execution_Order#Current_Limitations|Current Limitations]] section, it's been suggested that IE's current behavior with respect to the `readyState` property can adequately serve the use-case in question. This alternate proposal is very similar in spirit to the [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|previous section on explicit support for "text/cache"]] mime-type value.

The idea is that IE will begin fetching into the cache a script resource as soon as the `src` attribute of the dynamic script element is set. But IE will not execute the script (even if it finishes loading) until the script element is added to the DOM. However, the `readyState` property of the element, combined with the `onreadystatechange` handler listening for changes, can detect when the script has finished loading, by receiving the "loaded" value.

In this way, a script loader could "preload" a set of scripts all in parallel, but control their execution order by delaying the appending of the element to the DOM until execution is desired.

[[Category:Feature Request|Dynamic Script Execution Order]]

Dynamic Script Execution Order

2010-12-15T18:35:29Z

Getify: response to IE and `readyState` viability comment

This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.

Briefly, this issue has arisen because recent "nightlies" changes in both Mozilla Gecko and Webkit have broken the ability for script-loaders like [http://labjs.com LABjs] to be able to download scripts in parallel but ensure their execution order. As a result of the discussion, it's become apparent that both the spec for, and various current browser implementations around, dynamic script loading is incomplete in addressing this use case, and that some change needs to occur.

There is one main proposal that has surfaced from the discussions, with several other alternatives having been discussed. This page will try to distill the long email thread down and clearly present the main proposal, objections, and alternative suggestions.

Please feel free to join the discussion of this topic in the [[Talk:Dynamic_Script_Execution_Order]] area.

== Use Case Description ==
Script tags/elements can either:

a) appear in the HTML markup ("parser-inserted"), OR

b) be dynamically appended to the DOM using document.createElement() ("script-inserted")

Parser-inserted script tags, up until recent browser versions, had the undesirable performance behavior of loading and executing serially, blocking everything else while doing so. Recently, many browsers have improved the situation by loading the scripts in parallel, but still executing them in order.

On-demand (or dynamic) script loading has emerged in recent years for a variety of different reasons, most notably the performance improvements to address such concerns. It is desired by many different scenarios to be able to download scripts to a page completely independently of the loading of the rest of a page's resources, or even well after a page has finished loading ("on-demand").

Recent additions to HTML spec such as "defer" and "async" were intended to address the use-case for parser-inserted script elements, but their behaviors have been unhelpful for the on-demand loading use-case (script-inserted script elements).

Thus, script loaders (like [http://labjs.com LABjs]) were developed to give page authors an easy way to specify one or more scripts to load (regardless of when in the life-time of the page that loading is requested), and for as many of them as possible to load in parallel, and for those scripts to be loadable from any local or remote domain location, and for the script loader to be able to control the execution order (if the usage of the script loader's API expresses the need to) to preserve dependencies between the scripts.

Sometimes, dynamic script loading is used to load totally independent scripts, and thus "as fast as possible" execution is desired. Other times (and possibly more frequently), multiple scripts are loaded with some dependencies among them, requiring them to execute in a certain order.

What is needed is some facility by which a script loader can express that dynamic script loading either does or does not need execution order preserved among the queue of requested script loadings.

=== Current Limitations ===
Unfortunately, browser behavior around script-inserted script elements and their loading and execution behavior is splintered. There are, at present, two main camps of behavior:

a) in IE and Webkit (including Chrome), the default behavior for script-inserted script elements is for them all to execute in "as fast as possible" mode, meaning there's no guarantee about ordering. This effectively makes on-demand (dynamic) script loading impossible to work in parallel-mode if the resources in question have dependencies -- the only straight-forward way to handle things is to load each file and execute, serially, losing the parallel loading performance benefits.
<blockquote style="background-color: #EEEEEE">
I'm not sure if this is the case.

IE will start fetching resources without execution simply by setting the src attribute. Scripts will not execute, however, until they are added to the document. Since IE supports the readyState attribute and readystatechange event, it's possible to load scripts in parallel and execute them in order without resorting to invalid type attribute hack-ery.

<pre style="background-color:white" lang="javascript">
script= document.createElement("SCRIPT");
script.onreadystatechange= function(){
if(this.readyState == 'loaded')
/*
Network fetch is now complete, following
triggers synchronous execution.
*/
document.body.appendChild(this);
else if(this.readyState == "complete")
this.onreadystatechange= null;
}
script.src= "foo.js";
/* Network fetching begins now */
</pre>
</blockquote>

<blockquote style="background-color: #ccc">
I've experimented with such things heavily in the past, and I'm fairly suspicious that this is not reliable across various versions of IE (6-9), nor does it work reliably the same depending on if an element is already in the browser cache or not. I'm not 100% certain that what you suggest is flawed, but I have a strong hunch that it can be shown to have some holes in it for IE loading. I will try to create some test cases to prove or disprove.
<blockquote style="background-color: #EEEEEE">
When loading a script that is in the cache, IE requires the event handler be installed prior to setting the `src` attribute. Otherwise the element's transition to the "loaded" state will be missed. IE routinely "skips" ready state transitions when cached scripts are immediately inserted into the DOM so suspicion is understandable; however, delayed insertion works around this "problem". The script above has been tested in IE6-8 with scripts in a variety of caching states and found to work correctly.
</blockquote>

Moreover, you're suggesting something that is AFAIK only IE right now, and definitely appears to not be standardized. In the same way that I'm hesitant to continue pinning loading behavior on hacks like the invalid type attribute value, I wouldn't want to approach loading with this technique (even if it were proven reliable on all IE's under all caching circumstances) unless it was a serious proposal to the W3C to have this technique be the new standard (as opposed to the current proposal, as implemented by Mozilla and Webkit now).
<blockquote style="background-color: #EEEEEE">
I think you're right: Only IE impelements this event and property on script elements. The readystatechange event, however, is widely understood due to the XmlHttpRequest implementation and `readyState` property has been added to the `document` in WebKit, Mozilla and IE.
</blockquote>

That having been said, I think this is at least a viable candidate for "Alternate Proposals" and deserves to be listed as such. As always, I welcome input from the community on all the ideas presented here, including this one. But, since the main proposal (async=false) is already being implemented by at least two major browsers, I'm not sure if the tide will be changed or not.

</blockquote>

<blockquote style="background-color:#ddd;">
Also, the suggestion of handling the "preload" and deferred execution via the script tag's `readyState` property is very similar in spirit to the suggestion that was made to explicitly support [[Dynamic_Script_Execution_Order#Explicit_support_for_.22text.2Fcache.22_MIME_type_behavior|preloading into cache without execution]]. As I said, either of those two approaches might work, but they both put more of the onus of complexity in managing multiple dependencies on the high-level code (author, script loader, etc). I'm more in favor of this functionality being explicitly built-in natively into the queues. As always, I welcome comments to any side of this discussion.

[[User:Getify|Getify]] 18:35, 15 December 2010 (UTC)
</blockquote>

b) in Gecko and Opera, the default behavior for script-inserted script elements is for them all to load in parallel, but execute serially in insertion order. Technically, this makes it impossible to dynamically load independent script elements and have them execute in "as fast as possible" mode.

As described above, both behaviors are desirable under different circumstances, but each of the two camps provides only one behavior, and no way to straightforwardly achieve the other. This obviously creates a big nightmare interoperability-wise when trying to provide a general script loader cross-browser.

Since it is observed that the behavior in (a) is more detrimental (race-condition wise) for the case where dependencies exist, script loaders like LABjs had to find some way around this problem while still attempting the best possible parallel loading performance. However, the trick used is hacky and not completely reliable -- yet it is the best way to solve the use-case in <s>IE and </s>Webkit.

For Gecko/Opera, the concession was just (silently) made that the lesser-common use case of "as fast as possible" wasn't possible, but degraded fine to "insertion order execution", while keeping the parallel loading benefits.

<blockquote style="background-color: #EEEEEE">
Gecko's strict execution order creates dependencies between scripts which are unrelated and prevents the ability mitigate the impact of server outages / network latency. This is exacerbated by the fact that Gecko, unlike IE and WebKit, provides no mechanism to <b>remove</b> scripts from the execution queue.

Consider the case where JSONP is used to provide auto-completion. The user types "hello" and the JSONP request is made; however, the "currently" loading script is out-of-date as soon as the user modifies his search to "hello world". Gecko's algorithm requires the out-of-date request load and execute before the second request.
</blockquote>

Recently, Gecko landed a [http://hg.mozilla.org/mozilla-central/rev/a60414d076b5 patch] to the trunk that stopped Gecko's existing behavior of preserving execution order, making script-inserted script elements now execute in "as fast as possible" mode similiar to IE/Webkit. Unfortunately, the "workaround" used in IE/Webkit (described in the next section) for dealing with parallel loading and execution-order dependencies does not work in Gecko, which means presently the use-case in question is now broken in Gecko trunk/FF4 nightlies.

Moreover, Webkit recently landed a [http://trac.webkit.org/changeset/67245 patch] to the trunk that stopped Webkit's non-standard but long-held behavior (also used in the "workaround" described in the next section) of loading into cache script resources with an unrecognized "type" value, but silently not executing them. This behvaior (while hacky) is central to being able to address the use-case in question in Webkit, so at present, Webkit nightlies are now also entirely broken on the use-case (though in a different way than Gecko).

Both the Gecko change and the Webkit change are well-intentioned, as they are bringing the respective browser more in line with the HTML spec. However, what's really been demonstrated is that the HTML spec is not properly handling this use-case, and so the goal is not to address the browser issues raised with more awkward hacks, but to address the shortcomings of the spec first, and then encourage all browsers to adhere to such.

<blockquote style="background-color: #EEEEEE">
Considering Internet Explorer's readyState implementation provides a means of both parallel loading and preserving execution order can be achieved, perhaps its "readyState" property and onreadystatechange event should be included.
</blockquote>

=== Current Usage and Workarounds ===
To work around the limitation in IE/Webkit(prior to the above noted patch) of not being able to rely on script order execution for parallel loaded scripts, a "preloading" trick was developed. This trick relied on non-standard (but long-held) behavior in these browsers that a script-inserted script element with an unrecognized "type" value (such as "script/cache") would be fetched/loaded, but would not execute. This had the effect of loading the resource into cache, and then firing the "load" handlers to let the page know when the resource was completely in cache.

Assuming that the resource was served with proper caching headers, and was in fact in the cache, it could then be executed (nearly) immediately when it was the proper execution order time by re-requesting the same resource via another script-inserted script element with the proper "text/javascript" type value, pulling the resource from the cache and executing it, without another server round-trip.

Of course, the assumption of proper cache headers is a huge one, and not at all reliable. Some recent estimates by performance optimization specialists have suggested as much as 70% of scripts across the internet are not served with proper caching headers, which means that such scripts would be completely ineffective if loaded using this (or a similar) technique. The script resource would end up being loaded completely a second-time, and the "near immediate" execution would obviously be false, and thus race conditions would ensue.

It's important to note at this point that the new <link rel=prefetch> facility has been suggested as a better workaround, but it suffers the same ill-fated assumption of script cacheability. Still others have suggested "new Image().src=..." or the [http://www.phpied.com/preload-then-execute/ <object> preloading trick] suggested by Stoyan Stefanov. Again, these tricks unwisely assume cacheability, for the "preloading" trick to solve the use-case in question.

=== At Risk ===
Currently, there are several large/popular web sites which are either currently (or who intend to soon) use LABjs in such a way as to run afoul of the new Gecko and Webkit behavioral changes with LABjs failing to operate properly. It's important to note that the problems of race conditions can be subtle and hard to detect, and so merely loading up such sites and failing to observe overt failure is not sufficient.

Sites which are known to have LABjs loading techniques in place with currently broken (or susceptible to such breakage in the near future) behavior are:

* [http://twitter.com Twitter]
* [http://zappos.com Zappos]
* [http://vimeo.com Vimeo]
* [http://mefeedia.com MeFeedia]
* [http://blog.getify.com Getify Solutions blog (my blog)]
* [http://flensed.com flensed Flash+JavaScript browser shims (cross-domain Ajax, cross-browser cookies, etc)]

Rather than getting hung up in the syntax of usage in LABjs that is or is not going to break, it's best to just think of the problem this way:

Does a site need to load more than one script, at least one of which comes from a remote domain location (like a CDN), and for which among the scripts there's at least one execution-order dependency among them? If so, then that site is susceptible to the current/future breakage if the HTML spec (and browsers) do not address this use case.

A common example (in use on many sites) of such might be loading:

* jQuery from the CDN
* jQuery-UI from the CDN
* plugins and usage code in one or more local files
* Google Analytics from the Google domain

Note that the emergence of popular script frameworks and their hosting on public CDN's is leading to more and more sites loading scripts from both local and remote locations, and also to loading more files that have dependencies (rather than the practice of concat'ing all files into one file to avoid dependency issues).

Any site which fits a profile like the above, and which might currently (many do), or in the future want to, use a script loader to improve their loading performance, will fail to achieve what they want cross-browser and in a performant way, if the HTML spec (and browsers) do not address the use case.

=== Benefits ===
The benefits of addressing both behaviors directly (without "preloading" tricks and bad assumption reliance) have been implied in the above discussion, but in short are:

a) clear and simplified code for script loaders, which leads to easier use by authors of more pages, which in turn leads to better web performance (as demonstrated clearly by intelligent script loading techniques as compared to just simple <script> tags in HTML markup)

b) full access to either/both of the execution-order behaviors (as the author sees fit), regardless of browser

c) avoiding reliance on bad assumptions (like cacheability) as a sufficient way to address the use-case

=== External Discussions of this Feature ===

* <cite>[http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html W3C public-html email thread]</cite>

* <cite>[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 W3C Bug #11295]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>

* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>

* <cite>[http://hsivonen.iki.fi/script-execution/ HTML5 Script Execution Changes in Firefox 4 Beta 7]</cite>

* <cite>[http://blog.getify.com/2010/10/labjs-w3c-brief-update/ LABjs and W3C... brief update]</cite>

* <cite>[http://blog.getify.com/2010/10/ff4-script-loaders-and-order-preservation/ FF4, script loaders, and order preservation]</cite>

== Proposed Solutions ==

=== My Solution ===
The current proposal most well supported from the email discussion thread, and the one which I feel makes most sense, is described here.

The HTML spec already defines the "async" attribute for parser-inserted script tags, which when set to "true", changes their execution order behavior to be like script-inserted script-elements (in IE/Webkit), which is that they load in parallel and execute "as fast as possible" (ostensibly because the author is expressing no dependencies between multiple such "async"-marked scripts). Parser-inserted script elements without "async" (or with it set to false) behave as before and expected, which is that they load in parallel but execute in order.

However, the HTML spec does not define the "async" property (or any such behavior) for script-inserted script nodes (such as those created by a script loader). Instead, the spec implies that "async=true" like behavior is always true for such script-inserted script elements.

What is proposed is:

a) Script-inserted script elements should have (and respect the value of) an "async" property which is basically identical to the "async" attribute for parser-inserted script elements. That is, script elements with the "async" property set to "true" will behave accordingly, as will script elements with the "async" property set to false.

Essentially, the proposal is to mirror the "async" attribute behavior of parser-inserted script elements as an "async" property on script-inserted script elements. This has the benefit of using an existing facility and extending it (from current spec) in a way that is sensisble and symmetric with its current definition.
<blockquote style="background-color: #EFEFEF">
The scriptgroup or `readyState` alternate proposals allow for dependency management to be done in high-level code. The singular syncrhonized execution queue proposed here introduces artificial dependencies, undermining some of the benefits dynamic script loading provides.
</blockquote>

<blockquote style="background-color: #ccc;">
It's important to note that `async=false` scripts will load in a separate queue from `async=true` scripts. It's not that all scripts will now be forced into this insertion-order-execution queue. An author (or script loader) can chose which queue to put a script loading into based on the needs of the page and the resource. If I have a few scripts that are unrelated to each other and the main page (like Google Analytics, social sharing buttons, etc), I'll load those via `async=true`. For other scripts, where order matters for dependency sake, I'll use `async=false`. I think having both those queues available to high-level code is enough control over loading to serve the majority of use-cases pretty well.
</blockquote>

b) Furthermore, to aid in "feature-detection" of such new behavior, the proposal is to have the default value for the "async" property of script-inserted script elements be "true" (and of course the associated behavior thereof).

There are two major benefits to (b). One is that it provides a way to feature test such new behavior by not just looking for the existence of the "async" property on script elements, but specifically that the default value is "true" (which is opposite of what it would currently/normally be). Secondly, defaulting to "async=true" behavior for script-inserted script elements would preserve the default behavior of IE and Webkit, meaning there'd be less of a chance of breaking existing web content in either of those two browsers.

It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.

==== Proposal Amendment: Events ====
In addition to standardizing how scripts load and execute, it's also important to standardize the load and error events, and under what circumstances they fire, etc. Without reliable load/error events, the main proposal is not reliable and is thus unhelpful for the use-case.

A script-inserted script element must fire the "load" event only once, when:

a) immediately after the resource finishes loading, but before parsing/execution, AND

b) the script element loads any non-empty content (that is, it was a successful HTTP request), AND

c) the script element has either loaded from the remote location, or is loaded from the brower cache

Specifically, the script "load" event must come immediately between the script element finishing loading and the script element being parsed/executed. If the script resource successfully loads, nothing should interrupt the sequence of fininshing loading, the "load" event firing, and the script being parsed/executed.

A script-inserted script element must fire the "error" event only once, when:

a) immediately after a loading failure for the resource is detected (that is, an HTTP error received, such as 404, 500, 503, etc).

Either the "load" or "error" event, but not both, will fire, and only once, for every script-inserted script element.

NOTE: "load" and "error" events on script-inserted script elements must fire synchronously to ensure event reliability.

A case may be made for adding the "load" and "error" events as described here to parser-inserted script elements as well.

==== Processing Model ====
Script inserted script elements will have an "async" property that defaults to "true". If the author does not change the value, all such requested script loadings will be in their own "queue" and will default to "as fast as possible" execution behavior. For any script elements that the author sets "async=false", those scripts will load in a separate "queue", and will execute in insertion order only. Again, these two "queues" will operate strictly independent of each other.

==== Processing Model Details (without the event amendment) ====

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node.

When a previously-created script element node loses its parser-insertedness, if the element doesn't have the async content attribute, set the force-async flag to true and false otherwise.

When a script element node obtains the async content attribute (via setAttribute, setAttributeNode, setAttributeNS, by the fragment parser or the XSLTProcessor adding the attribute, etc.), set the force-async flag to false. (Note that calling removeAttribute("async") doesn't modify the force-async flag.)

The async IDL attribute must behave as follows:
* Upon setting, set the force-async flag to false and then reflect the async content attribute.
* Upon getting, if the force-async flag is true, return true. Otherwise, reflect the async content attribute.

In step 13. of http://www.whatwg.org/specs/web-apps/current-work/#running-a-script before the case "If the element has a src attribute" add a case:
If the script has a src attribute and the async IDL property getter returns false,
The element must be added to the queue of ordered script-inserted external scripts of the Document of the script element at the time the running a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run these steps:
# If the queue of ordered script-inserted external scripts is empty or the first script in the queue of ordered script-inserted external scripts has not been fetched yet, abort these steps.
# Execute the first script in the queue of ordered script-inserted external scripts.
# Remove the first script from queue of ordered script-inserted external scripts.
# Goto step #1.

Modify step 5 of http://www.whatwg.org/specs/web-apps/current-work/#the-end to say:
Spin the event loop until the set of scripts that will execute as soon as possible is empty and the queue of ordered script-inserted external scripts is empty.

==== Limitations ====
The two behaviors being identified solve either the case where no dependencies exist, or where a linear dependency chain exists (and which the script elements can be requested to execute in that order). It is possible that some authors have a more complex non-linear dependency chain that they would like to express. This would obviously require a much more complex API and spec change, and since that use-case has not (yet) surfaced as a particularly main-stream request, I believe it would be overengineering to try to address it with this proposed change set.

In addition, it's been duly noted that it's undesirable (and potentially confusing/problematic) to intentionally build in the inconsistency of having the "async" attribute (for parser-inserted scripts) and the "async" property (for script-inserted scripts) have different default values ("false" for the attribute, "true" for the property).

It's also been a point of discussion whether or not such a spec change has enough "carrot" to entice the browser vendors (namely IE and Webkit) to implement the behavior. Moreover, there's been some concern that if the default value for the "async" property were made to be "false" (like the attribute) to be more consistent and conservative, then it would possibly give the perception to IE and Webkit of "losing" some performance to cut out their default "as fast as possible" behavior.

=== Alternate Proposals ===
One early proposal on the email list was to introduce an entirely new property like "ordered" which an author could add to a script-inserted script element to instruct the browser to put it into the queue of execution-order-preserving script loadings. While such a property would address the use case, it introduces another property and thus more complicates the issue. It also fails to address the current spec inconsistency (which is confusing to new comers) that "async" is not a present/respected property in mirror of the attribute of the same name.

Another suggestion was a "waitFor" property that would be added to script elements and would specify a list of one or more DOM id's of other script elements that the current script should "wait for" in terms of execution. Again, this would solve the use case, but in a more complicated way, and there are concerns that it would be too confusing for the normal use-case.

Several suggestions have come in the form of creating explicit "preloading" (similar to <link rel=prefetch>), but as described above, "preloading" to solve this use case is a non-ideal hack and highly susceptible to breakage if the script fails to be sent with proper caching headers.

It's also been suggested that since this type of behavior is somewhat complicated, it may be better to intentionally obfuscate or complicate any such facility in the HTML, so as to make the barrier-to-entry rather high and force users to know what they are doing before doing it.

It's been suggested that "defer" already preserves execution order. However, "defer" is only defined for parser-inserted scripts, and thus is not applicable to the use-case in question from an on-demand point of view. Also, "defer" scripts explicitly way for DOMContentLoaded, even if they're ready to execute sooner. So this is less than desired.

Yet another proposal is a "document.executeScripts()" API, where an author can specify multiple sets of scripts that can load in parallel and it will enforce their execution order. A variation on that same idea was to use the "importScripts" from the Web Workers spec, however "importScripts" is synchronous (undesirable performance wise, obviously). The main downside (besides extra API complication) to "document.executeScripts()" is that there seem to be quite a few script execution properties/behaviors (including "document.currentScript" and charset override) which would have to be duplicated into this API facility.

==== "Script Group" element ====
One recent alternate proposal bears some special consideration, as it seems like it might be a decent option (although certainly more of a radical change for the spec and for browsers to implement). But it has the appearance of being pretty straightforward and semantic for authors to use, perhaps even more so than using "async".

The proposal is to create a new HTML element, called perhaps <scriptGroup>, <collection>, etc. Specifically, this element must be able to be inserted wherever a <script> element can currently be inserted. The "script group" element is intended to signify that all script elements added to it must perserve insertion execution order. This element wouldn't have much (but still some, explained in a moment) meaning in a parser-inserted context, since parser-inserted scripts already preserve order among themselves.

An advantage of the "script group" element would be to give a direct and easy way to attach event listeners ("load" and "error") to the entire group, rather than having to internally track events for each element if all you care about is the final "load" event, for instance. In the case of event handling, the "script group" element would have perhaps some benefit even in parser-inserted (markup) context.

The element would need to have an "id" property, and possibly attributes for "load" and "error" events.

A variation on how to look at this proposal is that a "script group" element could have an attribute/property on it (perhaps called "ordered") which would allow the group to either be order preserved or not. This would make the "script group" element much more useful in the parser-inserted context, as it would sort of be a shortcut to setting "async=true" on all the child script elements.

The "script group" element might look like this:

<scriptGroup id="group1">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

Or, with the "ordered" attribute to explicitly control ordering behavior for the group:

<scriptGroup id="group1" ordered="true">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

<scriptGroup id="group2" ordered="false" onload="alldone();">
<script src="baz.js"></script>
<script src="far.js"></script>
<script src="zab.js"></script>
</scriptGroup>

While the "script group" element is definitely more complicated to define and implement, it does have some semantic advantages for authors, and it also would significantly reduce the internal complexity of script loaders like LABjs. It would give authors (either directly or through script loaders) the flexibility to group scripts together into one of the two aforementioned behaviors (execution "as fast as possible" or "in insertion order"), and to easily access both behaviors in the same page.

==== Explicit support for "text/cache" MIME type behavior ====
Yet another alternate proposal has been suggested in the [[Talk:Dynamic_Script_Execution_Order]] thread.

Essentially, the proposal is that <script> tags directly support being declared with a `type` value of "text/cache". The behavior would be that the script resource is fetched, as the load events fired, as normal, but that the script itself would not be executed. Then later, at the desired time, the script in that element could be executed by changing the `type` value from "text/cache" to "text/javascript".

The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.

==== readyState "preloading" ====
Per the suggestion/comment added to the above [[Dynamic_Script_Execution_Order#Current_Limitations|Current Limitations]] section, it's been suggested that IE's current behavior with respect to the `readyState` property can adequately serve the use-case in question.

The idea is that IE will begin fetching into the cache a script resource as soon as the `src` attribute of the dynamic script element is set. But IE will not execute the script (even if it finishes loading) until the script element is added to the DOM. However, the `readyState` property of the element, combined with the `onreadystatechange` handler listening for changes, can detect when the script has finished loading, by receiving the "loaded" value.

In this way, a script loader could "preload" a set of scripts all in parallel, but control their execution order by delaying the appending of the element to the DOM until execution is desired.

[[Category:Feature Request|Dynamic Script Execution Order]]

Dynamic Script Execution Order

2010-12-15T18:10:00Z

Getify: response to high-level code comment

This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.

Briefly, this issue has arisen because recent "nightlies" changes in both Mozilla Gecko and Webkit have broken the ability for script-loaders like [http://labjs.com LABjs] to be able to download scripts in parallel but ensure their execution order. As a result of the discussion, it's become apparent that both the spec for, and various current browser implementations around, dynamic script loading is incomplete in addressing this use case, and that some change needs to occur.

There is one main proposal that has surfaced from the discussions, with several other alternatives having been discussed. This page will try to distill the long email thread down and clearly present the main proposal, objections, and alternative suggestions.

Please feel free to join the discussion of this topic in the [[Talk:Dynamic_Script_Execution_Order]] area.

== Use Case Description ==
Script tags/elements can either:

a) appear in the HTML markup ("parser-inserted"), OR

b) be dynamically appended to the DOM using document.createElement() ("script-inserted")

Parser-inserted script tags, up until recent browser versions, had the undesirable performance behavior of loading and executing serially, blocking everything else while doing so. Recently, many browsers have improved the situation by loading the scripts in parallel, but still executing them in order.

On-demand (or dynamic) script loading has emerged in recent years for a variety of different reasons, most notably the performance improvements to address such concerns. It is desired by many different scenarios to be able to download scripts to a page completely independently of the loading of the rest of a page's resources, or even well after a page has finished loading ("on-demand").

Recent additions to HTML spec such as "defer" and "async" were intended to address the use-case for parser-inserted script elements, but their behaviors have been unhelpful for the on-demand loading use-case (script-inserted script elements).

Thus, script loaders (like [http://labjs.com LABjs]) were developed to give page authors an easy way to specify one or more scripts to load (regardless of when in the life-time of the page that loading is requested), and for as many of them as possible to load in parallel, and for those scripts to be loadable from any local or remote domain location, and for the script loader to be able to control the execution order (if the usage of the script loader's API expresses the need to) to preserve dependencies between the scripts.

Sometimes, dynamic script loading is used to load totally independent scripts, and thus "as fast as possible" execution is desired. Other times (and possibly more frequently), multiple scripts are loaded with some dependencies among them, requiring them to execute in a certain order.

What is needed is some facility by which a script loader can express that dynamic script loading either does or does not need execution order preserved among the queue of requested script loadings.

=== Current Limitations ===
Unfortunately, browser behavior around script-inserted script elements and their loading and execution behavior is splintered. There are, at present, two main camps of behavior:

a) in IE and Webkit (including Chrome), the default behavior for script-inserted script elements is for them all to execute in "as fast as possible" mode, meaning there's no guarantee about ordering. This effectively makes on-demand (dynamic) script loading impossible to work in parallel-mode if the resources in question have dependencies -- the only straight-forward way to handle things is to load each file and execute, serially, losing the parallel loading performance benefits.
<blockquote style="background-color: #EEEEEE">
I'm not sure if this is the case.

IE will start fetching resources without execution simply by setting the src attribute. Scripts will not execute, however, until they are added to the document. Since IE supports the readyState attribute and readystatechange event, it's possible to load scripts in parallel and execute them in order without resorting to invalid type attribute hack-ery.

<pre style="background-color:white" lang="javascript">
script= document.createElement("SCRIPT");
script.onreadystatechange= function(){
if(this.readyState == 'loaded')
/*
Network fetch is now complete, following
triggers synchronous execution.
*/
document.body.appendChild(this);
else if(this.readyState == "complete")
this.onreadystatechange= null;
}
script.src= "foo.js";
/* Network fetching begins now */
</pre>
</blockquote>

<blockquote style="background-color: #ccc">
I've experimented with such things heavily in the past, and I'm fairly suspicious that this is not reliable across various versions of IE (6-9), nor does it work reliably the same depending on if an element is already in the browser cache or not. I'm not 100% certain that what you suggest is flawed, but I have a strong hunch that it can be shown to have some holes in it for IE loading. I will try to create some test cases to prove or disprove.

Moreover, you're suggesting something that is AFAIK only IE right now, and definitely appears to not be standardized. In the same way that I'm hesitant to continue pinning loading behavior on hacks like the invalid type attribute value, I wouldn't want to approach loading with this technique (even if it were proven reliable on all IE's under all caching circumstances) unless it was a serious proposal to the W3C to have this technique be the new standard (as opposed to the current proposal, as implemented by Mozilla and Webkit now).

That having been said, I think this is at least a viable candidate for "Alternate Proposals" and deserves to be listed as such. As always, I welcome input from the community on all the ideas presented here, including this one. But, since the main proposal (async=false) is already being implemented by at least two major browsers, I'm not sure if the tide will be changed or not.
</blockquote>

b) in Gecko and Opera, the default behavior for script-inserted script elements is for them all to load in parallel, but execute serially in insertion order. Technically, this makes it impossible to dynamically load independent script elements and have them execute in "as fast as possible" mode.

As described above, both behaviors are desirable under different circumstances, but each of the two camps provides only one behavior, and no way to straightforwardly achieve the other. This obviously creates a big nightmare interoperability-wise when trying to provide a general script loader cross-browser.

Since it is observed that the behavior in (a) is more detrimental (race-condition wise) for the case where dependencies exist, script loaders like LABjs had to find some way around this problem while still attempting the best possible parallel loading performance. However, the trick used is hacky and not completely reliable -- yet it is the best way to solve the use-case in <s>IE and </s>Webkit.

For Gecko/Opera, the concession was just (silently) made that the lesser-common use case of "as fast as possible" wasn't possible, but degraded fine to "insertion order execution", while keeping the parallel loading benefits.

<blockquote style="background-color: #EEEEEE">
Gecko's strict execution order creates dependencies between scripts which are unrelated and prevents the ability mitigate the impact of server outages / network latency. This is exacerbated by the fact that Gecko, unlike IE and WebKit, provides no mechanism to <b>remove</b> scripts from the execution queue.

Consider the case where JSONP is used to provide auto-completion. The user types "hello" and the JSONP request is made; however, the "currently" loading script is out-of-date as soon as the user modifies his search to "hello world". Gecko's algorithm requires the out-of-date request load and execute before the second request.
</blockquote>

Recently, Gecko landed a [http://hg.mozilla.org/mozilla-central/rev/a60414d076b5 patch] to the trunk that stopped Gecko's existing behavior of preserving execution order, making script-inserted script elements now execute in "as fast as possible" mode similiar to IE/Webkit. Unfortunately, the "workaround" used in IE/Webkit (described in the next section) for dealing with parallel loading and execution-order dependencies does not work in Gecko, which means presently the use-case in question is now broken in Gecko trunk/FF4 nightlies.

Moreover, Webkit recently landed a [http://trac.webkit.org/changeset/67245 patch] to the trunk that stopped Webkit's non-standard but long-held behavior (also used in the "workaround" described in the next section) of loading into cache script resources with an unrecognized "type" value, but silently not executing them. This behvaior (while hacky) is central to being able to address the use-case in question in Webkit, so at present, Webkit nightlies are now also entirely broken on the use-case (though in a different way than Gecko).

Both the Gecko change and the Webkit change are well-intentioned, as they are bringing the respective browser more in line with the HTML spec. However, what's really been demonstrated is that the HTML spec is not properly handling this use-case, and so the goal is not to address the browser issues raised with more awkward hacks, but to address the shortcomings of the spec first, and then encourage all browsers to adhere to such.

<blockquote style="background-color: #EEEEEE">
Considering Internet Explorer's readyState implementation provides a means of both parallel loading and preserving execution order can be achieved, perhaps its "readyState" property and onreadystatechange event should be included.
</blockquote>

=== Current Usage and Workarounds ===
To work around the limitation in IE/Webkit(prior to the above noted patch) of not being able to rely on script order execution for parallel loaded scripts, a "preloading" trick was developed. This trick relied on non-standard (but long-held) behavior in these browsers that a script-inserted script element with an unrecognized "type" value (such as "script/cache") would be fetched/loaded, but would not execute. This had the effect of loading the resource into cache, and then firing the "load" handlers to let the page know when the resource was completely in cache.

Assuming that the resource was served with proper caching headers, and was in fact in the cache, it could then be executed (nearly) immediately when it was the proper execution order time by re-requesting the same resource via another script-inserted script element with the proper "text/javascript" type value, pulling the resource from the cache and executing it, without another server round-trip.

Of course, the assumption of proper cache headers is a huge one, and not at all reliable. Some recent estimates by performance optimization specialists have suggested as much as 70% of scripts across the internet are not served with proper caching headers, which means that such scripts would be completely ineffective if loaded using this (or a similar) technique. The script resource would end up being loaded completely a second-time, and the "near immediate" execution would obviously be false, and thus race conditions would ensue.

It's important to note at this point that the new <link rel=prefetch> facility has been suggested as a better workaround, but it suffers the same ill-fated assumption of script cacheability. Still others have suggested "new Image().src=..." or the [http://www.phpied.com/preload-then-execute/ <object> preloading trick] suggested by Stoyan Stefanov. Again, these tricks unwisely assume cacheability, for the "preloading" trick to solve the use-case in question.

=== At Risk ===
Currently, there are several large/popular web sites which are either currently (or who intend to soon) use LABjs in such a way as to run afoul of the new Gecko and Webkit behavioral changes with LABjs failing to operate properly. It's important to note that the problems of race conditions can be subtle and hard to detect, and so merely loading up such sites and failing to observe overt failure is not sufficient.

Sites which are known to have LABjs loading techniques in place with currently broken (or susceptible to such breakage in the near future) behavior are:

* [http://twitter.com Twitter]
* [http://zappos.com Zappos]
* [http://vimeo.com Vimeo]
* [http://mefeedia.com MeFeedia]
* [http://blog.getify.com Getify Solutions blog (my blog)]
* [http://flensed.com flensed Flash+JavaScript browser shims (cross-domain Ajax, cross-browser cookies, etc)]

Rather than getting hung up in the syntax of usage in LABjs that is or is not going to break, it's best to just think of the problem this way:

Does a site need to load more than one script, at least one of which comes from a remote domain location (like a CDN), and for which among the scripts there's at least one execution-order dependency among them? If so, then that site is susceptible to the current/future breakage if the HTML spec (and browsers) do not address this use case.

A common example (in use on many sites) of such might be loading:

* jQuery from the CDN
* jQuery-UI from the CDN
* plugins and usage code in one or more local files
* Google Analytics from the Google domain

Note that the emergence of popular script frameworks and their hosting on public CDN's is leading to more and more sites loading scripts from both local and remote locations, and also to loading more files that have dependencies (rather than the practice of concat'ing all files into one file to avoid dependency issues).

Any site which fits a profile like the above, and which might currently (many do), or in the future want to, use a script loader to improve their loading performance, will fail to achieve what they want cross-browser and in a performant way, if the HTML spec (and browsers) do not address the use case.

=== Benefits ===
The benefits of addressing both behaviors directly (without "preloading" tricks and bad assumption reliance) have been implied in the above discussion, but in short are:

a) clear and simplified code for script loaders, which leads to easier use by authors of more pages, which in turn leads to better web performance (as demonstrated clearly by intelligent script loading techniques as compared to just simple <script> tags in HTML markup)

b) full access to either/both of the execution-order behaviors (as the author sees fit), regardless of browser

c) avoiding reliance on bad assumptions (like cacheability) as a sufficient way to address the use-case

=== External Discussions of this Feature ===

* <cite>[http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html W3C public-html email thread]</cite>

* <cite>[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 W3C Bug #11295]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>

* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>

* <cite>[http://hsivonen.iki.fi/script-execution/ HTML5 Script Execution Changes in Firefox 4 Beta 7]</cite>

* <cite>[http://blog.getify.com/2010/10/labjs-w3c-brief-update/ LABjs and W3C... brief update]</cite>

* <cite>[http://blog.getify.com/2010/10/ff4-script-loaders-and-order-preservation/ FF4, script loaders, and order preservation]</cite>

== Proposed Solutions ==

=== My Solution ===
The current proposal most well supported from the email discussion thread, and the one which I feel makes most sense, is described here.

The HTML spec already defines the "async" attribute for parser-inserted script tags, which when set to "true", changes their execution order behavior to be like script-inserted script-elements (in IE/Webkit), which is that they load in parallel and execute "as fast as possible" (ostensibly because the author is expressing no dependencies between multiple such "async"-marked scripts). Parser-inserted script elements without "async" (or with it set to false) behave as before and expected, which is that they load in parallel but execute in order.

However, the HTML spec does not define the "async" property (or any such behavior) for script-inserted script nodes (such as those created by a script loader). Instead, the spec implies that "async=true" like behavior is always true for such script-inserted script elements.

What is proposed is:

a) Script-inserted script elements should have (and respect the value of) an "async" property which is basically identical to the "async" attribute for parser-inserted script elements. That is, script elements with the "async" property set to "true" will behave accordingly, as will script elements with the "async" property set to false.

Essentially, the proposal is to mirror the "async" attribute behavior of parser-inserted script elements as an "async" property on script-inserted script elements. This has the benefit of using an existing facility and extending it (from current spec) in a way that is sensisble and symmetric with its current definition.
<blockquote style="background-color: #EFEFEF">
The scriptgroup or `readyState` alternate proposals allow for dependency management to be done in high-level code. The singular syncrhonized execution queue proposed here introduces artificial dependencies, undermining some of the benefits dynamic script loading provides.
</blockquote>

<blockquote style="background-color: #ccc;">
It's important to note that `async=false` scripts will load in a separate queue from `async=true` scripts. It's not that all scripts will now be forced into this insertion-order-execution queue. An author (or script loader) can chose which queue to put a script loading into based on the needs of the page and the resource. If I have a few scripts that are unrelated to each other and the main page (like Google Analytics, social sharing buttons, etc), I'll load those via `async=true`. For other scripts, where order matters for dependency sake, I'll use `async=false`. I think having both those queues available to high-level code is enough control over loading to serve the majority of use-cases pretty well.
</blockquote>

b) Furthermore, to aid in "feature-detection" of such new behavior, the proposal is to have the default value for the "async" property of script-inserted script elements be "true" (and of course the associated behavior thereof).

There are two major benefits to (b). One is that it provides a way to feature test such new behavior by not just looking for the existence of the "async" property on script elements, but specifically that the default value is "true" (which is opposite of what it would currently/normally be). Secondly, defaulting to "async=true" behavior for script-inserted script elements would preserve the default behavior of IE and Webkit, meaning there'd be less of a chance of breaking existing web content in either of those two browsers.

It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.

==== Proposal Amendment: Events ====
In addition to standardizing how scripts load and execute, it's also important to standardize the load and error events, and under what circumstances they fire, etc. Without reliable load/error events, the main proposal is not reliable and is thus unhelpful for the use-case.

A script-inserted script element must fire the "load" event only once, when:

a) immediately after the resource finishes loading, but before parsing/execution, AND

b) the script element loads any non-empty content (that is, it was a successful HTTP request), AND

c) the script element has either loaded from the remote location, or is loaded from the brower cache

Specifically, the script "load" event must come immediately between the script element finishing loading and the script element being parsed/executed. If the script resource successfully loads, nothing should interrupt the sequence of fininshing loading, the "load" event firing, and the script being parsed/executed.

A script-inserted script element must fire the "error" event only once, when:

a) immediately after a loading failure for the resource is detected (that is, an HTTP error received, such as 404, 500, 503, etc).

Either the "load" or "error" event, but not both, will fire, and only once, for every script-inserted script element.

NOTE: "load" and "error" events on script-inserted script elements must fire synchronously to ensure event reliability.

A case may be made for adding the "load" and "error" events as described here to parser-inserted script elements as well.

==== Processing Model ====
Script inserted script elements will have an "async" property that defaults to "true". If the author does not change the value, all such requested script loadings will be in their own "queue" and will default to "as fast as possible" execution behavior. For any script elements that the author sets "async=false", those scripts will load in a separate "queue", and will execute in insertion order only. Again, these two "queues" will operate strictly independent of each other.

==== Processing Model Details (without the event amendment) ====

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node.

When a previously-created script element node loses its parser-insertedness, if the element doesn't have the async content attribute, set the force-async flag to true and false otherwise.

When a script element node obtains the async content attribute (via setAttribute, setAttributeNode, setAttributeNS, by the fragment parser or the XSLTProcessor adding the attribute, etc.), set the force-async flag to false. (Note that calling removeAttribute("async") doesn't modify the force-async flag.)

The async IDL attribute must behave as follows:
* Upon setting, set the force-async flag to false and then reflect the async content attribute.
* Upon getting, if the force-async flag is true, return true. Otherwise, reflect the async content attribute.

In step 13. of http://www.whatwg.org/specs/web-apps/current-work/#running-a-script before the case "If the element has a src attribute" add a case:
If the script has a src attribute and the async IDL property getter returns false,
The element must be added to the queue of ordered script-inserted external scripts of the Document of the script element at the time the running a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run these steps:
# If the queue of ordered script-inserted external scripts is empty or the first script in the queue of ordered script-inserted external scripts has not been fetched yet, abort these steps.
# Execute the first script in the queue of ordered script-inserted external scripts.
# Remove the first script from queue of ordered script-inserted external scripts.
# Goto step #1.

Modify step 5 of http://www.whatwg.org/specs/web-apps/current-work/#the-end to say:
Spin the event loop until the set of scripts that will execute as soon as possible is empty and the queue of ordered script-inserted external scripts is empty.

==== Limitations ====
The two behaviors being identified solve either the case where no dependencies exist, or where a linear dependency chain exists (and which the script elements can be requested to execute in that order). It is possible that some authors have a more complex non-linear dependency chain that they would like to express. This would obviously require a much more complex API and spec change, and since that use-case has not (yet) surfaced as a particularly main-stream request, I believe it would be overengineering to try to address it with this proposed change set.

In addition, it's been duly noted that it's undesirable (and potentially confusing/problematic) to intentionally build in the inconsistency of having the "async" attribute (for parser-inserted scripts) and the "async" property (for script-inserted scripts) have different default values ("false" for the attribute, "true" for the property).

It's also been a point of discussion whether or not such a spec change has enough "carrot" to entice the browser vendors (namely IE and Webkit) to implement the behavior. Moreover, there's been some concern that if the default value for the "async" property were made to be "false" (like the attribute) to be more consistent and conservative, then it would possibly give the perception to IE and Webkit of "losing" some performance to cut out their default "as fast as possible" behavior.

=== Alternate Proposals ===
One early proposal on the email list was to introduce an entirely new property like "ordered" which an author could add to a script-inserted script element to instruct the browser to put it into the queue of execution-order-preserving script loadings. While such a property would address the use case, it introduces another property and thus more complicates the issue. It also fails to address the current spec inconsistency (which is confusing to new comers) that "async" is not a present/respected property in mirror of the attribute of the same name.

Another suggestion was a "waitFor" property that would be added to script elements and would specify a list of one or more DOM id's of other script elements that the current script should "wait for" in terms of execution. Again, this would solve the use case, but in a more complicated way, and there are concerns that it would be too confusing for the normal use-case.

Several suggestions have come in the form of creating explicit "preloading" (similar to <link rel=prefetch>), but as described above, "preloading" to solve this use case is a non-ideal hack and highly susceptible to breakage if the script fails to be sent with proper caching headers.

It's also been suggested that since this type of behavior is somewhat complicated, it may be better to intentionally obfuscate or complicate any such facility in the HTML, so as to make the barrier-to-entry rather high and force users to know what they are doing before doing it.

It's been suggested that "defer" already preserves execution order. However, "defer" is only defined for parser-inserted scripts, and thus is not applicable to the use-case in question from an on-demand point of view. Also, "defer" scripts explicitly way for DOMContentLoaded, even if they're ready to execute sooner. So this is less than desired.

Yet another proposal is a "document.executeScripts()" API, where an author can specify multiple sets of scripts that can load in parallel and it will enforce their execution order. A variation on that same idea was to use the "importScripts" from the Web Workers spec, however "importScripts" is synchronous (undesirable performance wise, obviously). The main downside (besides extra API complication) to "document.executeScripts()" is that there seem to be quite a few script execution properties/behaviors (including "document.currentScript" and charset override) which would have to be duplicated into this API facility.

==== "Script Group" element ====
One recent alternate proposal bears some special consideration, as it seems like it might be a decent option (although certainly more of a radical change for the spec and for browsers to implement). But it has the appearance of being pretty straightforward and semantic for authors to use, perhaps even more so than using "async".

The proposal is to create a new HTML element, called perhaps <scriptGroup>, <collection>, etc. Specifically, this element must be able to be inserted wherever a <script> element can currently be inserted. The "script group" element is intended to signify that all script elements added to it must perserve insertion execution order. This element wouldn't have much (but still some, explained in a moment) meaning in a parser-inserted context, since parser-inserted scripts already preserve order among themselves.

An advantage of the "script group" element would be to give a direct and easy way to attach event listeners ("load" and "error") to the entire group, rather than having to internally track events for each element if all you care about is the final "load" event, for instance. In the case of event handling, the "script group" element would have perhaps some benefit even in parser-inserted (markup) context.

The element would need to have an "id" property, and possibly attributes for "load" and "error" events.

A variation on how to look at this proposal is that a "script group" element could have an attribute/property on it (perhaps called "ordered") which would allow the group to either be order preserved or not. This would make the "script group" element much more useful in the parser-inserted context, as it would sort of be a shortcut to setting "async=true" on all the child script elements.

The "script group" element might look like this:

<scriptGroup id="group1">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

Or, with the "ordered" attribute to explicitly control ordering behavior for the group:

<scriptGroup id="group1" ordered="true">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

<scriptGroup id="group2" ordered="false" onload="alldone();">
<script src="baz.js"></script>
<script src="far.js"></script>
<script src="zab.js"></script>
</scriptGroup>

While the "script group" element is definitely more complicated to define and implement, it does have some semantic advantages for authors, and it also would significantly reduce the internal complexity of script loaders like LABjs. It would give authors (either directly or through script loaders) the flexibility to group scripts together into one of the two aforementioned behaviors (execution "as fast as possible" or "in insertion order"), and to easily access both behaviors in the same page.

==== Explicit support for "text/cache" MIME type behavior ====
Yet another alternate proposal has been suggested in the [[Talk:Dynamic_Script_Execution_Order]] thread.

Essentially, the proposal is that <script> tags directly support being declared with a `type` value of "text/cache". The behavior would be that the script resource is fetched, as the load events fired, as normal, but that the script itself would not be executed. Then later, at the desired time, the script in that element could be executed by changing the `type` value from "text/cache" to "text/javascript".

The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.

==== readyState "preloading" ====
Per the suggestion/comment added to the above [[Dynamic_Script_Execution_Order#Current_Limitations|Current Limitations]] section, it's been suggested that IE's current behavior with respect to the `readyState` property can adequately serve the use-case in question.

The idea is that IE will begin fetching into the cache a script resource as soon as the `src` attribute of the dynamic script element is set. But IE will not execute the script (even if it finishes loading) until the script element is added to the DOM. However, the `readyState` property of the element, combined with the `onreadystatechange` handler listening for changes, can detect when the script has finished loading, by receiving the "loaded" value.

In this way, a script loader could "preload" a set of scripts all in parallel, but control their execution order by delaying the appending of the element to the DOM until execution is desired.

[[Category:Feature Request|Dynamic Script Execution Order]]

Dynamic Script Execution Order

2010-12-14T22:17:29Z

Getify: adding "readyState preloading" alternate proposal

This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.

Briefly, this issue has arisen because recent "nightlies" changes in both Mozilla Gecko and Webkit have broken the ability for script-loaders like [http://labjs.com LABjs] to be able to download scripts in parallel but ensure their execution order. As a result of the discussion, it's become apparent that both the spec for, and various current browser implementations around, dynamic script loading is incomplete in addressing this use case, and that some change needs to occur.

There is one main proposal that has surfaced from the discussions, with several other alternatives having been discussed. This page will try to distill the long email thread down and clearly present the main proposal, objections, and alternative suggestions.

Please feel free to join the discussion of this topic in the [[Talk:Dynamic_Script_Execution_Order]] area.

== Use Case Description ==
Script tags/elements can either:

a) appear in the HTML markup ("parser-inserted"), OR

b) be dynamically appended to the DOM using document.createElement() ("script-inserted")

Parser-inserted script tags, up until recent browser versions, had the undesirable performance behavior of loading and executing serially, blocking everything else while doing so. Recently, many browsers have improved the situation by loading the scripts in parallel, but still executing them in order.

On-demand (or dynamic) script loading has emerged in recent years for a variety of different reasons, most notably the performance improvements to address such concerns. It is desired by many different scenarios to be able to download scripts to a page completely independently of the loading of the rest of a page's resources, or even well after a page has finished loading ("on-demand").

Recent additions to HTML spec such as "defer" and "async" were intended to address the use-case for parser-inserted script elements, but their behaviors have been unhelpful for the on-demand loading use-case (script-inserted script elements).

Thus, script loaders (like [http://labjs.com LABjs]) were developed to give page authors an easy way to specify one or more scripts to load (regardless of when in the life-time of the page that loading is requested), and for as many of them as possible to load in parallel, and for those scripts to be loadable from any local or remote domain location, and for the script loader to be able to control the execution order (if the usage of the script loader's API expresses the need to) to preserve dependencies between the scripts.

Sometimes, dynamic script loading is used to load totally independent scripts, and thus "as fast as possible" execution is desired. Other times (and possibly more frequently), multiple scripts are loaded with some dependencies among them, requiring them to execute in a certain order.

What is needed is some facility by which a script loader can express that dynamic script loading either does or does not need execution order preserved among the queue of requested script loadings.

=== Current Limitations ===
Unfortunately, browser behavior around script-inserted script elements and their loading and execution behavior is splintered. There are, at present, two main camps of behavior:

a) in IE and Webkit (including Chrome), the default behavior for script-inserted script elements is for them all to execute in "as fast as possible" mode, meaning there's no guarantee about ordering. This effectively makes on-demand (dynamic) script loading impossible to work in parallel-mode if the resources in question have dependencies -- the only straight-forward way to handle things is to load each file and execute, serially, losing the parallel loading performance benefits.
<blockquote style="background-color: #EEEEEE">
I'm not sure if this is the case.

IE will start fetching resources without execution simply by setting the src attribute. Scripts will not execute, however, until they are added to the document. Since IE supports the readyState attribute and readystatechange event, it's possible to load scripts in parallel and execute them in order without resorting to invalid type attribute hack-ery.

<pre style="background-color:white" lang="javascript">
script= document.createElement("SCRIPT");
script.onreadystatechange= function(){
if(this.readyState == 'loaded')
/*
Network fetch is now complete, following
triggers synchronous execution.
*/
document.body.appendChild(this);
else if(this.readyState == "complete")
this.onreadystatechange= null;
}
script.src= "foo.js";
/* Network fetching begins now */
</pre>
</blockquote>

<blockquote style="background-color: #ccc">
I've experimented with such things heavily in the past, and I'm fairly suspicious that this is not reliable across various versions of IE (6-9), nor does it work reliably the same depending on if an element is already in the browser cache or not. I'm not 100% certain that what you suggest is flawed, but I have a strong hunch that it can be shown to have some holes in it for IE loading. I will try to create some test cases to prove or disprove.

Moreover, you're suggesting something that is AFAIK only IE right now, and definitely appears to not be standardized. In the same way that I'm hesitant to continue pinning loading behavior on hacks like the invalid type attribute value, I wouldn't want to approach loading with this technique (even if it were proven reliable on all IE's under all caching circumstances) unless it was a serious proposal to the W3C to have this technique be the new standard (as opposed to the current proposal, as implemented by Mozilla and Webkit now).

That having been said, I think this is at least a viable candidate for "Alternate Proposals" and deserves to be listed as such. As always, I welcome input from the community on all the ideas presented here, including this one. But, since the main proposal (async=false) is already being implemented by at least two major browsers, I'm not sure if the tide will be changed or not.
</blockquote>

b) in Gecko and Opera, the default behavior for script-inserted script elements is for them all to load in parallel, but execute serially in insertion order. Technically, this makes it impossible to dynamically load independent script elements and have them execute in "as fast as possible" mode.

As described above, both behaviors are desirable under different circumstances, but each of the two camps provides only one behavior, and no way to straightforwardly achieve the other. This obviously creates a big nightmare interoperability-wise when trying to provide a general script loader cross-browser.

Since it is observed that the behavior in (a) is more detrimental (race-condition wise) for the case where dependencies exist, script loaders like LABjs had to find some way around this problem while still attempting the best possible parallel loading performance. However, the trick used is hacky and not completely reliable -- yet it is the best way to solve the use-case in <s>IE and </s>Webkit.

For Gecko/Opera, the concession was just (silently) made that the lesser-common use case of "as fast as possible" wasn't possible, but degraded fine to "insertion order execution", while keeping the parallel loading benefits.

<blockquote style="background-color: #EEEEEE">
Gecko's strict execution order creates dependencies between scripts which are unrelated and prevents the ability mitigate the impact of server outages / network latency. This is exacerbated by the fact that Gecko, unlike IE and WebKit, provides no mechanism to <b>remove</b> scripts from the execution queue.

Consider the case where JSONP is used to provide auto-completion. The user types "hello" and the JSONP request is made; however, the "currently" loading script is out-of-date as soon as the user modifies his search to "hello world". Gecko's algorithm requires the out-of-date request load and execute before the second request.
</blockquote>

Recently, Gecko landed a [http://hg.mozilla.org/mozilla-central/rev/a60414d076b5 patch] to the trunk that stopped Gecko's existing behavior of preserving execution order, making script-inserted script elements now execute in "as fast as possible" mode similiar to IE/Webkit. Unfortunately, the "workaround" used in IE/Webkit (described in the next section) for dealing with parallel loading and execution-order dependencies does not work in Gecko, which means presently the use-case in question is now broken in Gecko trunk/FF4 nightlies.

Moreover, Webkit recently landed a [http://trac.webkit.org/changeset/67245 patch] to the trunk that stopped Webkit's non-standard but long-held behavior (also used in the "workaround" described in the next section) of loading into cache script resources with an unrecognized "type" value, but silently not executing them. This behvaior (while hacky) is central to being able to address the use-case in question in Webkit, so at present, Webkit nightlies are now also entirely broken on the use-case (though in a different way than Gecko).

Both the Gecko change and the Webkit change are well-intentioned, as they are bringing the respective browser more in line with the HTML spec. However, what's really been demonstrated is that the HTML spec is not properly handling this use-case, and so the goal is not to address the browser issues raised with more awkward hacks, but to address the shortcomings of the spec first, and then encourage all browsers to adhere to such.

<blockquote style="background-color: #EEEEEE">
Considering Internet Explorer's readyState implementation provides a means of both parallel loading and preserving execution order can be achieved, perhaps its "readyState" property and onreadystatechange event should be included.
</blockquote>

=== Current Usage and Workarounds ===
To work around the limitation in IE/Webkit(prior to the above noted patch) of not being able to rely on script order execution for parallel loaded scripts, a "preloading" trick was developed. This trick relied on non-standard (but long-held) behavior in these browsers that a script-inserted script element with an unrecognized "type" value (such as "script/cache") would be fetched/loaded, but would not execute. This had the effect of loading the resource into cache, and then firing the "load" handlers to let the page know when the resource was completely in cache.

Assuming that the resource was served with proper caching headers, and was in fact in the cache, it could then be executed (nearly) immediately when it was the proper execution order time by re-requesting the same resource via another script-inserted script element with the proper "text/javascript" type value, pulling the resource from the cache and executing it, without another server round-trip.

Of course, the assumption of proper cache headers is a huge one, and not at all reliable. Some recent estimates by performance optimization specialists have suggested as much as 70% of scripts across the internet are not served with proper caching headers, which means that such scripts would be completely ineffective if loaded using this (or a similar) technique. The script resource would end up being loaded completely a second-time, and the "near immediate" execution would obviously be false, and thus race conditions would ensue.

It's important to note at this point that the new <link rel=prefetch> facility has been suggested as a better workaround, but it suffers the same ill-fated assumption of script cacheability. Still others have suggested "new Image().src=..." or the [http://www.phpied.com/preload-then-execute/ <object> preloading trick] suggested by Stoyan Stefanov. Again, these tricks unwisely assume cacheability, for the "preloading" trick to solve the use-case in question.

=== At Risk ===
Currently, there are several large/popular web sites which are either currently (or who intend to soon) use LABjs in such a way as to run afoul of the new Gecko and Webkit behavioral changes with LABjs failing to operate properly. It's important to note that the problems of race conditions can be subtle and hard to detect, and so merely loading up such sites and failing to observe overt failure is not sufficient.

Sites which are known to have LABjs loading techniques in place with currently broken (or susceptible to such breakage in the near future) behavior are:

* [http://twitter.com Twitter]
* [http://zappos.com Zappos]
* [http://vimeo.com Vimeo]
* [http://mefeedia.com MeFeedia]
* [http://blog.getify.com Getify Solutions blog (my blog)]
* [http://flensed.com flensed Flash+JavaScript browser shims (cross-domain Ajax, cross-browser cookies, etc)]

Rather than getting hung up in the syntax of usage in LABjs that is or is not going to break, it's best to just think of the problem this way:

Does a site need to load more than one script, at least one of which comes from a remote domain location (like a CDN), and for which among the scripts there's at least one execution-order dependency among them? If so, then that site is susceptible to the current/future breakage if the HTML spec (and browsers) do not address this use case.

A common example (in use on many sites) of such might be loading:

* jQuery from the CDN
* jQuery-UI from the CDN
* plugins and usage code in one or more local files
* Google Analytics from the Google domain

Note that the emergence of popular script frameworks and their hosting on public CDN's is leading to more and more sites loading scripts from both local and remote locations, and also to loading more files that have dependencies (rather than the practice of concat'ing all files into one file to avoid dependency issues).

Any site which fits a profile like the above, and which might currently (many do), or in the future want to, use a script loader to improve their loading performance, will fail to achieve what they want cross-browser and in a performant way, if the HTML spec (and browsers) do not address the use case.

=== Benefits ===
The benefits of addressing both behaviors directly (without "preloading" tricks and bad assumption reliance) have been implied in the above discussion, but in short are:

a) clear and simplified code for script loaders, which leads to easier use by authors of more pages, which in turn leads to better web performance (as demonstrated clearly by intelligent script loading techniques as compared to just simple <script> tags in HTML markup)

b) full access to either/both of the execution-order behaviors (as the author sees fit), regardless of browser

c) avoiding reliance on bad assumptions (like cacheability) as a sufficient way to address the use-case

=== External Discussions of this Feature ===

* <cite>[http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html W3C public-html email thread]</cite>

* <cite>[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 W3C Bug #11295]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>

* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>

* <cite>[http://hsivonen.iki.fi/script-execution/ HTML5 Script Execution Changes in Firefox 4 Beta 7]</cite>

* <cite>[http://blog.getify.com/2010/10/labjs-w3c-brief-update/ LABjs and W3C... brief update]</cite>

* <cite>[http://blog.getify.com/2010/10/ff4-script-loaders-and-order-preservation/ FF4, script loaders, and order preservation]</cite>

== Proposed Solutions ==

=== My Solution ===
The current proposal most well supported from the email discussion thread, and the one which I feel makes most sense, is described here.

The HTML spec already defines the "async" attribute for parser-inserted script tags, which when set to "true", changes their execution order behavior to be like script-inserted script-elements (in IE/Webkit), which is that they load in parallel and execute "as fast as possible" (ostensibly because the author is expressing no dependencies between multiple such "async"-marked scripts). Parser-inserted script elements without "async" (or with it set to false) behave as before and expected, which is that they load in parallel but execute in order.

However, the HTML spec does not define the "async" property (or any such behavior) for script-inserted script nodes (such as those created by a script loader). Instead, the spec implies that "async=true" like behavior is always true for such script-inserted script elements.

What is proposed is:

a) Script-inserted script elements should have (and respect the value of) an "async" property which is basically identical to the "async" attribute for parser-inserted script elements. That is, script elements with the "async" property set to "true" will behave accordingly, as will script elements with the "async" property set to false.

Essentially, the proposal is to mirror the "async" attribute behavior of parser-inserted script elements as an "async" property on script-inserted script elements. This has the benefit of using an existing facility and extending it (from current spec) in a way that is sensisble and symmetric with its current definition.

b) Furthermore, to aid in "feature-detection" of such new behavior, the proposal is to have the default value for the "async" property of script-inserted script elements be "true" (and of course the associated behavior thereof).

There are two major benefits to (b). One is that it provides a way to feature test such new behavior by not just looking for the existence of the "async" property on script elements, but specifically that the default value is "true" (which is opposite of what it would currently/normally be). Secondly, defaulting to "async=true" behavior for script-inserted script elements would preserve the default behavior of IE and Webkit, meaning there'd be less of a chance of breaking existing web content in either of those two browsers.

It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.

==== Proposal Amendment: Events ====
In addition to standardizing how scripts load and execute, it's also important to standardize the load and error events, and under what circumstances they fire, etc. Without reliable load/error events, the main proposal is not reliable and is thus unhelpful for the use-case.

A script-inserted script element must fire the "load" event only once, when:

a) immediately after the resource finishes loading, but before parsing/execution, AND

b) the script element loads any non-empty content (that is, it was a successful HTTP request), AND

c) the script element has either loaded from the remote location, or is loaded from the brower cache

Specifically, the script "load" event must come immediately between the script element finishing loading and the script element being parsed/executed. If the script resource successfully loads, nothing should interrupt the sequence of fininshing loading, the "load" event firing, and the script being parsed/executed.

A script-inserted script element must fire the "error" event only once, when:

a) immediately after a loading failure for the resource is detected (that is, an HTTP error received, such as 404, 500, 503, etc).

Either the "load" or "error" event, but not both, will fire, and only once, for every script-inserted script element.

NOTE: "load" and "error" events on script-inserted script elements must fire synchronously to ensure event reliability.

A case may be made for adding the "load" and "error" events as described here to parser-inserted script elements as well.

==== Processing Model ====
Script inserted script elements will have an "async" property that defaults to "true". If the author does not change the value, all such requested script loadings will be in their own "queue" and will default to "as fast as possible" execution behavior. For any script elements that the author sets "async=false", those scripts will load in a separate "queue", and will execute in insertion order only. Again, these two "queues" will operate strictly independent of each other.

==== Processing Model Details (without the event amendment) ====

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node.

When a previously-created script element node loses its parser-insertedness, if the element doesn't have the async content attribute, set the force-async flag to true and false otherwise.

When a script element node obtains the async content attribute (via setAttribute, setAttributeNode, setAttributeNS, by the fragment parser or the XSLTProcessor adding the attribute, etc.), set the force-async flag to false. (Note that calling removeAttribute("async") doesn't modify the force-async flag.)

The async IDL attribute must behave as follows:
* Upon setting, set the force-async flag to false and then reflect the async content attribute.
* Upon getting, if the force-async flag is true, return true. Otherwise, reflect the async content attribute.

In step 13. of http://www.whatwg.org/specs/web-apps/current-work/#running-a-script before the case "If the element has a src attribute" add a case:
If the script has a src attribute and the async IDL property getter returns false,
The element must be added to the queue of ordered script-inserted external scripts of the Document of the script element at the time the running a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run these steps:
# If the queue of ordered script-inserted external scripts is empty or the first script in the queue of ordered script-inserted external scripts has not been fetched yet, abort these steps.
# Execute the first script in the queue of ordered script-inserted external scripts.
# Remove the first script from queue of ordered script-inserted external scripts.
# Goto step #1.

Modify step 5 of http://www.whatwg.org/specs/web-apps/current-work/#the-end to say:
Spin the event loop until the set of scripts that will execute as soon as possible is empty and the queue of ordered script-inserted external scripts is empty.

==== Limitations ====
The two behaviors being identified solve either the case where no dependencies exist, or where a linear dependency chain exists (and which the script elements can be requested to execute in that order). It is possible that some authors have a more complex non-linear dependency chain that they would like to express. This would obviously require a much more complex API and spec change, and since that use-case has not (yet) surfaced as a particularly main-stream request, I believe it would be overengineering to try to address it with this proposed change set.

In addition, it's been duly noted that it's undesirable (and potentially confusing/problematic) to intentionally build in the inconsistency of having the "async" attribute (for parser-inserted scripts) and the "async" property (for script-inserted scripts) have different default values ("false" for the attribute, "true" for the property).

It's also been a point of discussion whether or not such a spec change has enough "carrot" to entice the browser vendors (namely IE and Webkit) to implement the behavior. Moreover, there's been some concern that if the default value for the "async" property were made to be "false" (like the attribute) to be more consistent and conservative, then it would possibly give the perception to IE and Webkit of "losing" some performance to cut out their default "as fast as possible" behavior.

=== Alternate Proposals ===
One early proposal on the email list was to introduce an entirely new property like "ordered" which an author could add to a script-inserted script element to instruct the browser to put it into the queue of execution-order-preserving script loadings. While such a property would address the use case, it introduces another property and thus more complicates the issue. It also fails to address the current spec inconsistency (which is confusing to new comers) that "async" is not a present/respected property in mirror of the attribute of the same name.

Another suggestion was a "waitFor" property that would be added to script elements and would specify a list of one or more DOM id's of other script elements that the current script should "wait for" in terms of execution. Again, this would solve the use case, but in a more complicated way, and there are concerns that it would be too confusing for the normal use-case.

Several suggestions have come in the form of creating explicit "preloading" (similar to <link rel=prefetch>), but as described above, "preloading" to solve this use case is a non-ideal hack and highly susceptible to breakage if the script fails to be sent with proper caching headers.

It's also been suggested that since this type of behavior is somewhat complicated, it may be better to intentionally obfuscate or complicate any such facility in the HTML, so as to make the barrier-to-entry rather high and force users to know what they are doing before doing it.

It's been suggested that "defer" already preserves execution order. However, "defer" is only defined for parser-inserted scripts, and thus is not applicable to the use-case in question from an on-demand point of view. Also, "defer" scripts explicitly way for DOMContentLoaded, even if they're ready to execute sooner. So this is less than desired.

Yet another proposal is a "document.executeScripts()" API, where an author can specify multiple sets of scripts that can load in parallel and it will enforce their execution order. A variation on that same idea was to use the "importScripts" from the Web Workers spec, however "importScripts" is synchronous (undesirable performance wise, obviously). The main downside (besides extra API complication) to "document.executeScripts()" is that there seem to be quite a few script execution properties/behaviors (including "document.currentScript" and charset override) which would have to be duplicated into this API facility.

==== "Script Group" element ====
One recent alternate proposal bears some special consideration, as it seems like it might be a decent option (although certainly more of a radical change for the spec and for browsers to implement). But it has the appearance of being pretty straightforward and semantic for authors to use, perhaps even more so than using "async".

The proposal is to create a new HTML element, called perhaps <scriptGroup>, <collection>, etc. Specifically, this element must be able to be inserted wherever a <script> element can currently be inserted. The "script group" element is intended to signify that all script elements added to it must perserve insertion execution order. This element wouldn't have much (but still some, explained in a moment) meaning in a parser-inserted context, since parser-inserted scripts already preserve order among themselves.

An advantage of the "script group" element would be to give a direct and easy way to attach event listeners ("load" and "error") to the entire group, rather than having to internally track events for each element if all you care about is the final "load" event, for instance. In the case of event handling, the "script group" element would have perhaps some benefit even in parser-inserted (markup) context.

The element would need to have an "id" property, and possibly attributes for "load" and "error" events.

A variation on how to look at this proposal is that a "script group" element could have an attribute/property on it (perhaps called "ordered") which would allow the group to either be order preserved or not. This would make the "script group" element much more useful in the parser-inserted context, as it would sort of be a shortcut to setting "async=true" on all the child script elements.

The "script group" element might look like this:

<scriptGroup id="group1">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

Or, with the "ordered" attribute to explicitly control ordering behavior for the group:

<scriptGroup id="group1" ordered="true">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

<scriptGroup id="group2" ordered="false" onload="alldone();">
<script src="baz.js"></script>
<script src="far.js"></script>
<script src="zab.js"></script>
</scriptGroup>

While the "script group" element is definitely more complicated to define and implement, it does have some semantic advantages for authors, and it also would significantly reduce the internal complexity of script loaders like LABjs. It would give authors (either directly or through script loaders) the flexibility to group scripts together into one of the two aforementioned behaviors (execution "as fast as possible" or "in insertion order"), and to easily access both behaviors in the same page.

==== Explicit support for "text/cache" MIME type behavior ====
Yet another alternate proposal has been suggested in the [[Talk:Dynamic_Script_Execution_Order]] thread.

Essentially, the proposal is that <script> tags directly support being declared with a `type` value of "text/cache". The behavior would be that the script resource is fetched, as the load events fired, as normal, but that the script itself would not be executed. Then later, at the desired time, the script in that element could be executed by changing the `type` value from "text/cache" to "text/javascript".

The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.

==== readyState "preloading" ====
Per the suggestion/comment added to the above [[Dynamic_Script_Execution_Order#Current_Limitations|Current Limitations]] section, it's been suggested that IE's current behavior with respect to the `readyState` property can adequately serve the use-case in question.

The idea is that IE will begin fetching into the cache a script resource as soon as the `src` attribute of the dynamic script element is set. But IE will not execute the script (even if it finishes loading) until the script element is added to the DOM. However, the `readyState` property of the element, combined with the `onreadystatechange` handler listening for changes, can detect when the script has finished loading, by receiving the "loaded" value.

In this way, a script loader could "preload" a set of scripts all in parallel, but control their execution order by delaying the appending of the element to the DOM until execution is desired.

[[Category:Feature Request|Dynamic Script Execution Order]]

Dynamic Script Execution Order

2010-12-14T22:09:19Z

Getify: response to comments

This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.

Briefly, this issue has arisen because recent "nightlies" changes in both Mozilla Gecko and Webkit have broken the ability for script-loaders like [http://labjs.com LABjs] to be able to download scripts in parallel but ensure their execution order. As a result of the discussion, it's become apparent that both the spec for, and various current browser implementations around, dynamic script loading is incomplete in addressing this use case, and that some change needs to occur.

There is one main proposal that has surfaced from the discussions, with several other alternatives having been discussed. This page will try to distill the long email thread down and clearly present the main proposal, objections, and alternative suggestions.

Please feel free to join the discussion of this topic in the [[Talk:Dynamic_Script_Execution_Order]] area.

== Use Case Description ==
Script tags/elements can either:

a) appear in the HTML markup ("parser-inserted"), OR

b) be dynamically appended to the DOM using document.createElement() ("script-inserted")

Parser-inserted script tags, up until recent browser versions, had the undesirable performance behavior of loading and executing serially, blocking everything else while doing so. Recently, many browsers have improved the situation by loading the scripts in parallel, but still executing them in order.

On-demand (or dynamic) script loading has emerged in recent years for a variety of different reasons, most notably the performance improvements to address such concerns. It is desired by many different scenarios to be able to download scripts to a page completely independently of the loading of the rest of a page's resources, or even well after a page has finished loading ("on-demand").

Recent additions to HTML spec such as "defer" and "async" were intended to address the use-case for parser-inserted script elements, but their behaviors have been unhelpful for the on-demand loading use-case (script-inserted script elements).

Thus, script loaders (like [http://labjs.com LABjs]) were developed to give page authors an easy way to specify one or more scripts to load (regardless of when in the life-time of the page that loading is requested), and for as many of them as possible to load in parallel, and for those scripts to be loadable from any local or remote domain location, and for the script loader to be able to control the execution order (if the usage of the script loader's API expresses the need to) to preserve dependencies between the scripts.

Sometimes, dynamic script loading is used to load totally independent scripts, and thus "as fast as possible" execution is desired. Other times (and possibly more frequently), multiple scripts are loaded with some dependencies among them, requiring them to execute in a certain order.

What is needed is some facility by which a script loader can express that dynamic script loading either does or does not need execution order preserved among the queue of requested script loadings.

=== Current Limitations ===
Unfortunately, browser behavior around script-inserted script elements and their loading and execution behavior is splintered. There are, at present, two main camps of behavior:

a) in IE and Webkit (including Chrome), the default behavior for script-inserted script elements is for them all to execute in "as fast as possible" mode, meaning there's no guarantee about ordering. This effectively makes on-demand (dynamic) script loading impossible to work in parallel-mode if the resources in question have dependencies -- the only straight-forward way to handle things is to load each file and execute, serially, losing the parallel loading performance benefits.
<blockquote style="background-color: #EEEEEE">
I'm not sure if this is the case.

IE will start fetching resources without execution simply by setting the src attribute. Scripts will not execute, however, until they are added to the document. Since IE supports the readyState attribute and readystatechange event, it's possible to load scripts in parallel and execute them in order without resorting to invalid type attribute hack-ery.

<pre style="background-color:white" lang="javascript">
script= document.createElement("SCRIPT");
script.onreadystatechange= function(){
if(this.readyState == 'loaded')
/*
Network fetch is now complete, following
triggers synchronous execution.
*/
document.body.appendChild(this);
else if(this.readyState == "complete")
this.onreadystatechange= null;
}
script.src= "foo.js";
/* Network fetching begins now */
</pre>
</blockquote>

<blockquote style="background-color: #ccc">
I've experimented with such things heavily in the past, and I'm fairly suspicious that this is not reliable across various versions of IE (6-9), nor does it work reliably the same depending on if an element is already in the browser cache or not. I'm not 100% certain that what you suggest is flawed, but I have a strong hunch that it can be shown to have some holes in it for IE loading. I will try to create some test cases to prove or disprove.

Moreover, you're suggesting something that is AFAIK only IE right now, and definitely appears to not be standardized. In the same way that I'm hesitant to continue pinning loading behavior on hacks like the invalid type attribute value, I wouldn't want to approach loading with this technique (even if it were proven reliable on all IE's under all caching circumstances) unless it was a serious proposal to the W3C to have this technique be the new standard (as opposed to the current proposal, as implemented by Mozilla and Webkit now).

That having been said, I think this is at least a viable candidate for "Alternate Proposals" and deserves to be listed as such. As always, I welcome input from the community on all the ideas presented here, including this one. But, since the main proposal (async=false) is already being implemented by at least two major browsers, I'm not sure if the tide will be changed or not.
</blockquote>

b) in Gecko and Opera, the default behavior for script-inserted script elements is for them all to load in parallel, but execute serially in insertion order. Technically, this makes it impossible to dynamically load independent script elements and have them execute in "as fast as possible" mode.

As described above, both behaviors are desirable under different circumstances, but each of the two camps provides only one behavior, and no way to straightforwardly achieve the other. This obviously creates a big nightmare interoperability-wise when trying to provide a general script loader cross-browser.

Since it is observed that the behavior in (a) is more detrimental (race-condition wise) for the case where dependencies exist, script loaders like LABjs had to find some way around this problem while still attempting the best possible parallel loading performance. However, the trick used is hacky and not completely reliable -- yet it is the best way to solve the use-case in <s>IE and </s>Webkit.

For Gecko/Opera, the concession was just (silently) made that the lesser-common use case of "as fast as possible" wasn't possible, but degraded fine to "insertion order execution", while keeping the parallel loading benefits.

<blockquote style="background-color: #EEEEEE">
Gecko's strict execution order creates dependencies between scripts which are unrelated and prevents the ability mitigate the impact of server outages / network latency. This is exacerbated by the fact that Gecko, unlike IE and WebKit, provides no mechanism to <b>remove</b> scripts from the execution queue.

Consider the case where JSONP is used to provide auto-completion. The user types "hello" and the JSONP request is made; however, the "currently" loading script is out-of-date as soon as the user modifies his search to "hello world". Gecko's algorithm requires the out-of-date request load and execute before the second request.
</blockquote>

Recently, Gecko landed a [http://hg.mozilla.org/mozilla-central/rev/a60414d076b5 patch] to the trunk that stopped Gecko's existing behavior of preserving execution order, making script-inserted script elements now execute in "as fast as possible" mode similiar to IE/Webkit. Unfortunately, the "workaround" used in IE/Webkit (described in the next section) for dealing with parallel loading and execution-order dependencies does not work in Gecko, which means presently the use-case in question is now broken in Gecko trunk/FF4 nightlies.

Moreover, Webkit recently landed a [http://trac.webkit.org/changeset/67245 patch] to the trunk that stopped Webkit's non-standard but long-held behavior (also used in the "workaround" described in the next section) of loading into cache script resources with an unrecognized "type" value, but silently not executing them. This behvaior (while hacky) is central to being able to address the use-case in question in Webkit, so at present, Webkit nightlies are now also entirely broken on the use-case (though in a different way than Gecko).

Both the Gecko change and the Webkit change are well-intentioned, as they are bringing the respective browser more in line with the HTML spec. However, what's really been demonstrated is that the HTML spec is not properly handling this use-case, and so the goal is not to address the browser issues raised with more awkward hacks, but to address the shortcomings of the spec first, and then encourage all browsers to adhere to such.

<blockquote style="background-color: #EEEEEE">
Considering Internet Explorer's readyState implementation provides a means of both parallel loading and preserving execution order can be achieved, perhaps its "readyState" property and onreadystatechange event should be included.
</blockquote>

=== Current Usage and Workarounds ===
To work around the limitation in IE/Webkit(prior to the above noted patch) of not being able to rely on script order execution for parallel loaded scripts, a "preloading" trick was developed. This trick relied on non-standard (but long-held) behavior in these browsers that a script-inserted script element with an unrecognized "type" value (such as "script/cache") would be fetched/loaded, but would not execute. This had the effect of loading the resource into cache, and then firing the "load" handlers to let the page know when the resource was completely in cache.

Assuming that the resource was served with proper caching headers, and was in fact in the cache, it could then be executed (nearly) immediately when it was the proper execution order time by re-requesting the same resource via another script-inserted script element with the proper "text/javascript" type value, pulling the resource from the cache and executing it, without another server round-trip.

Of course, the assumption of proper cache headers is a huge one, and not at all reliable. Some recent estimates by performance optimization specialists have suggested as much as 70% of scripts across the internet are not served with proper caching headers, which means that such scripts would be completely ineffective if loaded using this (or a similar) technique. The script resource would end up being loaded completely a second-time, and the "near immediate" execution would obviously be false, and thus race conditions would ensue.

It's important to note at this point that the new <link rel=prefetch> facility has been suggested as a better workaround, but it suffers the same ill-fated assumption of script cacheability. Still others have suggested "new Image().src=..." or the [http://www.phpied.com/preload-then-execute/ <object> preloading trick] suggested by Stoyan Stefanov. Again, these tricks unwisely assume cacheability, for the "preloading" trick to solve the use-case in question.

=== At Risk ===
Currently, there are several large/popular web sites which are either currently (or who intend to soon) use LABjs in such a way as to run afoul of the new Gecko and Webkit behavioral changes with LABjs failing to operate properly. It's important to note that the problems of race conditions can be subtle and hard to detect, and so merely loading up such sites and failing to observe overt failure is not sufficient.

Sites which are known to have LABjs loading techniques in place with currently broken (or susceptible to such breakage in the near future) behavior are:

* [http://twitter.com Twitter]
* [http://zappos.com Zappos]
* [http://vimeo.com Vimeo]
* [http://mefeedia.com MeFeedia]
* [http://blog.getify.com Getify Solutions blog (my blog)]
* [http://flensed.com flensed Flash+JavaScript browser shims (cross-domain Ajax, cross-browser cookies, etc)]

Rather than getting hung up in the syntax of usage in LABjs that is or is not going to break, it's best to just think of the problem this way:

Does a site need to load more than one script, at least one of which comes from a remote domain location (like a CDN), and for which among the scripts there's at least one execution-order dependency among them? If so, then that site is susceptible to the current/future breakage if the HTML spec (and browsers) do not address this use case.

A common example (in use on many sites) of such might be loading:

* jQuery from the CDN
* jQuery-UI from the CDN
* plugins and usage code in one or more local files
* Google Analytics from the Google domain

Note that the emergence of popular script frameworks and their hosting on public CDN's is leading to more and more sites loading scripts from both local and remote locations, and also to loading more files that have dependencies (rather than the practice of concat'ing all files into one file to avoid dependency issues).

Any site which fits a profile like the above, and which might currently (many do), or in the future want to, use a script loader to improve their loading performance, will fail to achieve what they want cross-browser and in a performant way, if the HTML spec (and browsers) do not address the use case.

=== Benefits ===
The benefits of addressing both behaviors directly (without "preloading" tricks and bad assumption reliance) have been implied in the above discussion, but in short are:

a) clear and simplified code for script loaders, which leads to easier use by authors of more pages, which in turn leads to better web performance (as demonstrated clearly by intelligent script loading techniques as compared to just simple <script> tags in HTML markup)

b) full access to either/both of the execution-order behaviors (as the author sees fit), regardless of browser

c) avoiding reliance on bad assumptions (like cacheability) as a sufficient way to address the use-case

=== External Discussions of this Feature ===

* <cite>[http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html W3C public-html email thread]</cite>

* <cite>[http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 W3C Bug #11295]</cite>

* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>

* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>

* <cite>[http://hsivonen.iki.fi/script-execution/ HTML5 Script Execution Changes in Firefox 4 Beta 7]</cite>

* <cite>[http://blog.getify.com/2010/10/labjs-w3c-brief-update/ LABjs and W3C... brief update]</cite>

* <cite>[http://blog.getify.com/2010/10/ff4-script-loaders-and-order-preservation/ FF4, script loaders, and order preservation]</cite>

== Proposed Solutions ==

=== My Solution ===
The current proposal most well supported from the email discussion thread, and the one which I feel makes most sense, is described here.

The HTML spec already defines the "async" attribute for parser-inserted script tags, which when set to "true", changes their execution order behavior to be like script-inserted script-elements (in IE/Webkit), which is that they load in parallel and execute "as fast as possible" (ostensibly because the author is expressing no dependencies between multiple such "async"-marked scripts). Parser-inserted script elements without "async" (or with it set to false) behave as before and expected, which is that they load in parallel but execute in order.

However, the HTML spec does not define the "async" property (or any such behavior) for script-inserted script nodes (such as those created by a script loader). Instead, the spec implies that "async=true" like behavior is always true for such script-inserted script elements.

What is proposed is:

a) Script-inserted script elements should have (and respect the value of) an "async" property which is basically identical to the "async" attribute for parser-inserted script elements. That is, script elements with the "async" property set to "true" will behave accordingly, as will script elements with the "async" property set to false.

Essentially, the proposal is to mirror the "async" attribute behavior of parser-inserted script elements as an "async" property on script-inserted script elements. This has the benefit of using an existing facility and extending it (from current spec) in a way that is sensisble and symmetric with its current definition.

b) Furthermore, to aid in "feature-detection" of such new behavior, the proposal is to have the default value for the "async" property of script-inserted script elements be "true" (and of course the associated behavior thereof).

There are two major benefits to (b). One is that it provides a way to feature test such new behavior by not just looking for the existence of the "async" property on script elements, but specifically that the default value is "true" (which is opposite of what it would currently/normally be). Secondly, defaulting to "async=true" behavior for script-inserted script elements would preserve the default behavior of IE and Webkit, meaning there'd be less of a chance of breaking existing web content in either of those two browsers.

It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.

==== Proposal Amendment: Events ====
In addition to standardizing how scripts load and execute, it's also important to standardize the load and error events, and under what circumstances they fire, etc. Without reliable load/error events, the main proposal is not reliable and is thus unhelpful for the use-case.

A script-inserted script element must fire the "load" event only once, when:

a) immediately after the resource finishes loading, but before parsing/execution, AND

b) the script element loads any non-empty content (that is, it was a successful HTTP request), AND

c) the script element has either loaded from the remote location, or is loaded from the brower cache

Specifically, the script "load" event must come immediately between the script element finishing loading and the script element being parsed/executed. If the script resource successfully loads, nothing should interrupt the sequence of fininshing loading, the "load" event firing, and the script being parsed/executed.

A script-inserted script element must fire the "error" event only once, when:

a) immediately after a loading failure for the resource is detected (that is, an HTTP error received, such as 404, 500, 503, etc).

Either the "load" or "error" event, but not both, will fire, and only once, for every script-inserted script element.

NOTE: "load" and "error" events on script-inserted script elements must fire synchronously to ensure event reliability.

A case may be made for adding the "load" and "error" events as described here to parser-inserted script elements as well.

==== Processing Model ====
Script inserted script elements will have an "async" property that defaults to "true". If the author does not change the value, all such requested script loadings will be in their own "queue" and will default to "as fast as possible" execution behavior. For any script elements that the author sets "async=false", those scripts will load in a separate "queue", and will execute in insertion order only. Again, these two "queues" will operate strictly independent of each other.

==== Processing Model Details (without the event amendment) ====

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node.

When a previously-created script element node loses its parser-insertedness, if the element doesn't have the async content attribute, set the force-async flag to true and false otherwise.

When a script element node obtains the async content attribute (via setAttribute, setAttributeNode, setAttributeNS, by the fragment parser or the XSLTProcessor adding the attribute, etc.), set the force-async flag to false. (Note that calling removeAttribute("async") doesn't modify the force-async flag.)

The async IDL attribute must behave as follows:
* Upon setting, set the force-async flag to false and then reflect the async content attribute.
* Upon getting, if the force-async flag is true, return true. Otherwise, reflect the async content attribute.

In step 13. of http://www.whatwg.org/specs/web-apps/current-work/#running-a-script before the case "If the element has a src attribute" add a case:
If the script has a src attribute and the async IDL property getter returns false,
The element must be added to the queue of ordered script-inserted external scripts of the Document of the script element at the time the running a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run these steps:
# If the queue of ordered script-inserted external scripts is empty or the first script in the queue of ordered script-inserted external scripts has not been fetched yet, abort these steps.
# Execute the first script in the queue of ordered script-inserted external scripts.
# Remove the first script from queue of ordered script-inserted external scripts.
# Goto step #1.

Modify step 5 of http://www.whatwg.org/specs/web-apps/current-work/#the-end to say:
Spin the event loop until the set of scripts that will execute as soon as possible is empty and the queue of ordered script-inserted external scripts is empty.

==== Limitations ====
The two behaviors being identified solve either the case where no dependencies exist, or where a linear dependency chain exists (and which the script elements can be requested to execute in that order). It is possible that some authors have a more complex non-linear dependency chain that they would like to express. This would obviously require a much more complex API and spec change, and since that use-case has not (yet) surfaced as a particularly main-stream request, I believe it would be overengineering to try to address it with this proposed change set.

In addition, it's been duly noted that it's undesirable (and potentially confusing/problematic) to intentionally build in the inconsistency of having the "async" attribute (for parser-inserted scripts) and the "async" property (for script-inserted scripts) have different default values ("false" for the attribute, "true" for the property).

It's also been a point of discussion whether or not such a spec change has enough "carrot" to entice the browser vendors (namely IE and Webkit) to implement the behavior. Moreover, there's been some concern that if the default value for the "async" property were made to be "false" (like the attribute) to be more consistent and conservative, then it would possibly give the perception to IE and Webkit of "losing" some performance to cut out their default "as fast as possible" behavior.

=== Alternate Proposals ===
One early proposal on the email list was to introduce an entirely new property like "ordered" which an author could add to a script-inserted script element to instruct the browser to put it into the queue of execution-order-preserving script loadings. While such a property would address the use case, it introduces another property and thus more complicates the issue. It also fails to address the current spec inconsistency (which is confusing to new comers) that "async" is not a present/respected property in mirror of the attribute of the same name.

Another suggestion was a "waitFor" property that would be added to script elements and would specify a list of one or more DOM id's of other script elements that the current script should "wait for" in terms of execution. Again, this would solve the use case, but in a more complicated way, and there are concerns that it would be too confusing for the normal use-case.

Several suggestions have come in the form of creating explicit "preloading" (similar to <link rel=prefetch>), but as described above, "preloading" to solve this use case is a non-ideal hack and highly susceptible to breakage if the script fails to be sent with proper caching headers.

It's also been suggested that since this type of behavior is somewhat complicated, it may be better to intentionally obfuscate or complicate any such facility in the HTML, so as to make the barrier-to-entry rather high and force users to know what they are doing before doing it.

It's been suggested that "defer" already preserves execution order. However, "defer" is only defined for parser-inserted scripts, and thus is not applicable to the use-case in question from an on-demand point of view. Also, "defer" scripts explicitly way for DOMContentLoaded, even if they're ready to execute sooner. So this is less than desired.

Yet another proposal is a "document.executeScripts()" API, where an author can specify multiple sets of scripts that can load in parallel and it will enforce their execution order. A variation on that same idea was to use the "importScripts" from the Web Workers spec, however "importScripts" is synchronous (undesirable performance wise, obviously). The main downside (besides extra API complication) to "document.executeScripts()" is that there seem to be quite a few script execution properties/behaviors (including "document.currentScript" and charset override) which would have to be duplicated into this API facility.

==== "Script Group" element ====
One recent alternate proposal bears some special consideration, as it seems like it might be a decent option (although certainly more of a radical change for the spec and for browsers to implement). But it has the appearance of being pretty straightforward and semantic for authors to use, perhaps even more so than using "async".

The proposal is to create a new HTML element, called perhaps <scriptGroup>, <collection>, etc. Specifically, this element must be able to be inserted wherever a <script> element can currently be inserted. The "script group" element is intended to signify that all script elements added to it must perserve insertion execution order. This element wouldn't have much (but still some, explained in a moment) meaning in a parser-inserted context, since parser-inserted scripts already preserve order among themselves.

An advantage of the "script group" element would be to give a direct and easy way to attach event listeners ("load" and "error") to the entire group, rather than having to internally track events for each element if all you care about is the final "load" event, for instance. In the case of event handling, the "script group" element would have perhaps some benefit even in parser-inserted (markup) context.

The element would need to have an "id" property, and possibly attributes for "load" and "error" events.

A variation on how to look at this proposal is that a "script group" element could have an attribute/property on it (perhaps called "ordered") which would allow the group to either be order preserved or not. This would make the "script group" element much more useful in the parser-inserted context, as it would sort of be a shortcut to setting "async=true" on all the child script elements.

The "script group" element might look like this:

<scriptGroup id="group1">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

Or, with the "ordered" attribute to explicitly control ordering behavior for the group:

<scriptGroup id="group1" ordered="true">
<script src="foo.js"></script>
<script src="bar.js"></script>
<script>
somethingInline();
</script>
</scriptGroup>

<scriptGroup id="group2" ordered="false" onload="alldone();">
<script src="baz.js"></script>
<script src="far.js"></script>
<script src="zab.js"></script>
</scriptGroup>

While the "script group" element is definitely more complicated to define and implement, it does have some semantic advantages for authors, and it also would significantly reduce the internal complexity of script loaders like LABjs. It would give authors (either directly or through script loaders) the flexibility to group scripts together into one of the two aforementioned behaviors (execution "as fast as possible" or "in insertion order"), and to easily access both behaviors in the same page.

==== Explicit support for "text/cache" MIME type behavior ====
Yet another alternate proposal has been suggested in the [[Talk:Dynamic_Script_Execution_Order]] thread.

Essentially, the proposal is that <script> tags directly support being declared with a `type` value of "text/cache". The behavior would be that the script resource is fetched, as the load events fired, as normal, but that the script itself would not be executed. Then later, at the desired time, the script in that element could be executed by changing the `type` value from "text/cache" to "text/javascript".

The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.

[[Category:Feature Request|Dynamic Script Execution Order]]

Dynamic Script Execution Order

2010-11-29T15:40:41Z

Getify: /* Proposal Amendment: Events */

Dynamic Script Execution Order

2010-11-26T20:15:13Z

Getify: /* External Discussions of this Feature */

Dynamic Script Execution Order

2010-11-04T21:09:09Z

Getify: adding link to the discussion thread

Dynamic Script Execution Order

2010-11-04T21:07:18Z

Getify: adding "text/cache" alternate proposal