[whatwg] Proposal for separating script downloads and execution

[Will Alexander]

On Feb 11, 2011 12:31 PM, "Will Alexander" <serverherder at gmail.com> wrote:
>
>
> 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 feature-detection or strictly
synchronous execution. 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 always 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.