[whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

Thanks Kyle, those comments were helpful. I've simplified and refined my proposal based on them and the others in this thread:
https://docs.google.com/document/d/1wLdTU3xPMKhBP0anS774Y4ZT2UQDqVhnQl3VnSceDJM/edit?hl=en&authkey=CJ6z2ZgO

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.

-N

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

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

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 
implementation.
2. requires less new additions (no extra function call), which means less 
complexity to work through semantics on (see above questions about 
`execute()` semantics)


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


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

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.
>
> https://bugs.webkit.org/show_bug.cgi?id=51650
> https://bugzilla.mozilla.org/show_bug.cgi?id=621553

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.


--Kyle