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
• 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?). 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. Getify 19:33, 6 March 2011 (UTC)

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
• 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. 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. Getify 19:33, 6 March 2011 (UTC)

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
• 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. Getify 19:33, 6 March 2011 (UTC)

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
• 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. 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. Getify 19:33, 6 March 2011 (UTC)