Talk:Script Execution Control

Discussion for 2.2.1.4 Limitations

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

Discussion for 2.3 Proposal

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.

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

Fetch error handling (DNS errors, 404 errors) is handled with no changes to current behavior.

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

In addition to programmatic preloading, scripts can also be preloaded in markup and later activated by scripts.

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

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.

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

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.

• 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. Getify 23:53, 4 March 2011 (UTC)
• They may say a lot of things. You stretching the "IE card" very thin. Glenn