[whatwg] Proposal for separating script downloads and execution

Thu Feb 3 17:13:50 PST 2011

On Thu, Feb 3, 2011 at 4:45 PM, Kyle Simpson <getify at gmail.com> wrote:
> ?> 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.

I'm not sure why you are narrowing the scope to "script loaders"? (I
imagine you're referring to js-libraries which help with loading
scripts faster?)

My idea was that webservers would output the above markup directly,
avoiding the need to go through special libraries at all.

>> 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'm not quite sure I follow you here. What I was thinking was that we
say that implementations MUST (in the rfc 2119 sense) start loading
the script immediately.

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

Sure, but we'd also want to fire some event once the script has been
fully downloaded so that the page doesn't have to use a timer and poll
to figure out when the download is done.

/ Jonas