[whatwg] Proposal for separating script downloads and execution

Thu Feb 3 16:45:56 PST 2011

?> One reason I like the noexecute proposal more than relying on
> readyState is that noexecute can be used in markup. I.e. you can do
> things like:
>
> <html>
> <head>
> <script src=a.js noexecute onload="...">
> <script src=b.js noexecute onload="...">
> <script src=c.js noexecute onload="...">
> </head>

Doesn't <link rel=prefetch> mostly address the use-case of 
load-but-don't-execute in markup? The reason script-inserted script elements 
need this capability is more advanced than any use-case for why you'd do so 
in markup. In other words, I can't imagine that a script loader would rely 
on adding script tags through markup (like with document.write() I guess?) 
rather than just using dynamic script elements.

For the sake of the argument though, I *can* see how the "noexecute" would 
be useful for *inline* script elements that you wanted to include in your 
markup. For instance, the gmail-mobile team does this by wrapping the inline 
script content in comments (and then later processing the code to execute 
it).

However, it's already possible to address that same use-case using existing 
behavior... by simple specifying a bogus `type` for the inline script 
element. Some JS templating solutions make use of this behavior, like:

What `noexecute` *would* bring additional to the use-case is the ability to 
directly execute the script block at a later time without having to process 
its contents manually. Currently, if you use the bogus type method, or the 
comment-wrapped-content method, you have to manually grab the content, 
process it, and re-inject it into a proper script element, which of course 
is slightly less performant.

I'm not sure that the slight performance hit of this use-case is important 
(or impactful) enough though to define a whole new attribute and its 
semantics/complications.

> Though of course, if people think that using readystate is enough then
> we can flesh out that solution too. We'd have to require that UAs
> start downloading the script as soon as .src is set, and that events
> fire at reasonable points in time, like when the script has been
> downloaded.

Yes, as I said earlier in the thread, I think we'd need to consider changing 
the "may" wording in the current spec language to "shall" or "will". And 
then we'd have to consider giving some basic framework language for an event 
mechanism. Technically, the "preloading" event mechanism isn't strictly 
necessary, but it's quite useful for several things you can't do without it, 
and so I really don't think it's worth adjusting the spec without also 
adding that part in.

> I think that we couldn't use the 'load' event has that
> might break existing pages which rely on 'load' not firing until the
> script has executed.

Agreed, "load" is a binary one-time event, and thus not suitable for 
overloading for this purpose. "readyState" is much more suitable since it 
defines a progression of states. XHR already makes good use of defining such 
an event mechanism, and so there's precedent to draw from here. In the case 
of preloading for scripts, there's probably just two states necessary: 
"uninitialized" and "complete". Haven't seen any use-cases for which any 
intermediate states (like "loading") would be useful, as they are in XHR.

--Kyle 