[whatwg] Proposal for separating script downloads and execution

[Glenn Maynard]

On Fri, Feb 11, 2011 at 12:57 PM, Will Alexander <
serverherder+whatwg at gmail.com> wrote:

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

In my proposal (which was intended as a further refinement of Nicholas's),
execute would only be permitted once the network load completes, and throw
an exception if called before then.

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

(I only suggested execute() being synchronous since it made sense in the
context of my proposal and it seemed like a useful, natural side-effect of
the rest of the proposal.)



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

Note that I didn't mean to propose changing existing event semantics; I
simply forgot that script events already had an onload event that means
something entirely different than the one described by Progress Events.  The
"finished loading from the network" event would need to have a different
name.

-- 
Glenn Maynard