[whatwg] Proposal for separating script downloads and execution
nzakas at yahoo-inc.com
Fri Feb 11 14:44:32 PST 2011
Thanks Kyle, those comments were helpful. I've simplified and refined my proposal based on them and the others in this thread:
Summary of changes:
* Changed "noexecute" to "preload"
* No HTML markup usage
* No change to "load" event
* Introduction of "preload" event
* Removed mention of "readyState"
I'd appreciate hearing feedback on this revision from everyone.
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Kyle Simpson
Sent: Friday, February 11, 2011 3:42 PM
To: whatwg at lists.whatwg.org
Cc: Will Alexander; Nicholas C. Zakas
Subject: Re: [whatwg] Proposal for separating script downloads and execution
> We've gone back and forth around implementation specifics, and now I'd
> like to get a general feeling on direction. It seems that enough people
> understand why a solution like this is important, both on the desktop and
> for mobile, so what are the next steps?
> Are there changes I can make to my proposal that would make it easier to
> implement and therefore more likely to have someone take a stab at
Nicholas, if you're sticking with your original proposal of the `noexecute`
on script elements, then a mechanism should be specified by which the event
can be detected for when the script finishes loading. As stated earlier,
`onload` isn't sufficient, since it doesn't fire until after a script has
finished (including execution). Are you proposing instead a new event, like
"onloadingcomplete" or something of that nature?
Otherwise, the next most obvious candidate for an event, using existing
precedent, would be the `readyState=loaded`, coupled with that event being
fired by `onreadystatechange`, as happens currently in IE (similar to XHR).
Once we have some event mechanism to detect when the script finishes
loading, then your original proposal breaks down to:
1. Add a `noexecute` property on dynamic script elements, default it to
false, let it be settable to true.
2. Add an `execute()` function.
For the `noexecute`, We need clearer definition on if this proposal is that
it's only a property on dynamic script elements, or is it also a boolean
attribute in markup script elements? If the proposal includes the markup
attribute, we need clearer definition around the semantics of how that would
be used. As stated, <script src="..." noexecute onload="this.execute()">
doesn't work (chicken-and-the-egg), so in place of that, what is a concrete
example of how the `noexecute` boolean attribute in markup would be used and
The `execute()` function needs further specification as to what happens if
execute() is called too early, or on a script that already executed, or on a
script that wasn't `noexecute`, as Will pointed out.
> Is there a concrete alternate proposal that's worth building out instead?
Aside from the event system questions, which is required for either
proposal, the "concrete alternate proposal" (from me) is simply:
1. Change the suggestion behavior of preloading before DOM-append to
required behavior, modeled as it is implemented in IE.
As to whether this one is more "worth building out" than your original
proposal, my support arguments are:
1. entirely uses existing precedent, both in wording in the spec and in IE's
2. requires less new additions (no extra function call), which means less
complexity to work through semantics on (see above questions about
I haven't heard on this thread any serious discussion of other workable
proposals besides those two. Correct me if I'm wrong.
> Early on it seemed there was general consensus that changing the existing
> MAY fetch-upon-src-assignment to MUST or SHOULD.
I'm not sure there's been consensus on this yet, but there's definitely been
some strong support by several people. I'd say the two proposals are about
even (maybe slightly in favor of `readyState`) in terms of vocalized support
> Since that is only
> tangential to this proposal, provides immediate benefit to existing code,
> and can satisfy use cases that do not require feature-detection or
> synchronous execution.
I'm not sure what you mean by "do not require feature-detection". I think
it's clear that both proposals need feature-detection to be useful. In both
cases, we're creating opt-in behavior, and you only want to opt-in to that
behavior (and, by extension, *not* use some other method/fallback) if the
behavior you want exists.
If I created several script elements, but don't attach them to the DOM, and
I assume (without feature-testing) that they are being fetched, then without
this feature they'll never load. So I'd definitely need to feature-test
before making that assumption.
Conversely, with `noexecute`, I'd definitely want to feature-test that
`noexecute` was going to in fact suppress execution, otherwise if I start
loading several scripts and they don't enforce execution order (which spec
says they shouldn't), then I've got race conditions.
> I'm hopeful the change would generate activity around these bug reports.
I think it's a mistake for those two bug reports not to make it clear that
an event system for detecting the load is a must. Without the event system,
a significant part of this use-case is impossible to achieve.
More information about the whatwg