[whatwg] Proposal for separating script downloads and execution

Thu Feb 3 13:52:27 PST 2011

On Tue, Feb 1, 2011 at 11:06 AM, Kyle Simpson <getify at gmail.com> wrote:
> ?> The major issue I have with the way the spec is written is that there is
> no way to feature detect this capability. I'd like this behavior (which I
> agree, is useful), to be more explicit so we can easily make use where
> available.
>
> I agree, the spec doesn't make it clear in its current wording how this
> could be feature-tested. And (as you know, Nicholas), I'm a firm believer
> that any new functionality *must* be feature-testable rather than
> browser-inferences or UA sniffing. :)
>
> However, the current IE implementation (with the additional `readyState`
> property) does actually provide a feasible feature-test (in fact, I'm
> working on a new revision of LABjs to take advantage of this functionality
> for IE).
>
> The feature-test for IE essentially looks for the presence of the
> `readyState` property on a newly created script element, and then also
> inspects its value, because in IE it always defaults to "uninitialized" as
> its value. The reason for having to also test the value is because Opera has
> had a present-but-non-functional `readyState` property on their script
> elements since like 9.2, with a default value of "loaded".
>
> If the spec considers adding an event system to this mechanism similar to or
> compatible with IE's existing mechanism, I think this could be a valid
> approach to feature-testing, assuming the browsers all agree to play nicely.
> :)

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>

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. 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. (This isn't a problem with the noexecute proposal
since that is opt-in).

/ Jonas