[whatwg] Proposal for separating script downloads and execution

[Will Alexander]

On Feb 11, 2011 10:41 AM, "Nicholas Zakas" <nzakas at yahoo-inc.com> wrote:
>
> 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?
>
Early on it seemed there was general consensus that changing the
existing MAY fetch-upon-src-assignment to MUST or SHOULD.  Since that
is only tangential to this proposal, provides immediate benefit to
existing code, and can satisfy use cases that do not require strictly
synchronous execution.

I'm hopeful the change would generate activity around these bug reports.

https://bugs.webkit.org/show_bug.cgi?id=51650
https://bugzilla.mozilla.org/show_bug.cgi?id=621553

If I am wrong in my assessment of the consensus, does it make sense to
consider that change outside of this proposal?

> 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 implementing?

I may have missed it, but what would execute() do if the url has not
been loaded?   Would it be similar to a synchronous XHR request, lead
to ASAP execution, or throw error?

> Is there a concrete alternate proposal that's worth building out instead?

If execute() must be synchronous, then readystate is not applicable.
Otherwise, while it should be considered, it would probably take
longer to describe and has no corresponding markup semantics.

Glenn's point about noexecute  being a natural extension of defer and
async is a good one, however neither of those required changing onload
semantics or introducing a new event type.  Readystate on the other
hand is already a well-known concept. Moreover, if history is any
indication, we'll continue using it to implement deferred exec for
awhile.