[whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

Once again, the problem with changing how src works is that there's no way to feature detect this change. It's completely opaque to developers and therefore not helpful in solving the problem.

Again, the reason I used readyState was for tracking the script's state. My doc states that if execute() is called on any script whose readyState is earlier than "loaded", then it throws an error; if it's called when readyState is "loaded", then the code is executed and the state is changed to "complete"; if it's called when readyState is "complete", nothing happens and the method returns false.

As I said before, I'm not married to all bits of this proposal. If there's some other way to achieve the same functionality, I'm all for it. The main goals are listed in the doc, and I'm happy to support any proposal that achieves all of them.

-N


-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Will Alexander
Sent: Friday, February 11, 2011 12:58 PM
To: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Proposal for separating script downloads and execution

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.