[whatwg] Proposal for separating script downloads and execution

[Kyle Simpson]

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

I still believe the feature-detect for my proposal is valid. It's obviously 
not ideal (often times feature-detects aren't), but I don't think we should 
suffer a more complicated solution just so we can get a slightly more 
graceful feature-detect, when the simpler solution has a functional 
feature-detect. So far, the feature-detect issue is the only thing I've 
heard Nicholas push back on with regards to my proposal.

To restate, the feature-detect for my proposal is:

(document.createElement("script").readyState == "uninitialized") // true 
only for IE, not for Opera or any others, currently

In fact, the precedent was already set (in the "async=false" 
proposal/discussion, which was officially adopted by the spec recently) for 
having a feature-detect that uses not only the presence of some property but 
its default value.

(document.createElement("script").async === true)

Many of the same reasonings I gave there for that type (slightly 
unconventional compared to previous ones) of feature detect are exactly the 
reasons I'm suggesting a similar pattern for `readyState`. Extending the 
feature-detect to use a property and its default value is a delicate way of 
balancing the need for a feature-detect without creating entirely new 
properties (more complexity) just so we can feature-detect.

While it isn't as pretty-looking, in the current state of how the browsers 
have implemented things, it IS workable. The set of browsers and their 
current support for `readyState` is a known-matrix. We know that only IE 
(and Opera) have it defined. And given the high visibility of this issue and 
our active evangelism efforts to the browser vendors, it's quite likely and 
reliable that all of them would know the nature of the `readyState` part of 
the proposal being the feature

The only wrinkle would have been Opera possibly changing the default value 
to "uninitialized" but not implementing the proposed underlying behavior. 
Thankfully, they already commented on this thread to indicate they would act 
in good faith to implement the full atomic nature of the proposal (not just 
part of it), so as to preserve the validity of the proposed feature-detect.

I know Nicholas has expressed reservations about that feature-detect. But I 
would say that there needs to be hard evidence of how it will break, not 
just premature fear that some browser vendor will go rogue on us and 
invalidate the expressed assumptions.


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

Firstly, I like the changes Nicholas made to his proposal. I think "preload" 
and "onpreload" are definitely clearer than "noExecute" and whatever the 
"onfinishedloading" would have had to be. I still think his proposal is more 
complicated (and thus faces a more uphill journey to spec acceptance and 
browser adoption) than `readyState` preloading, but it's definitely clearer 
and more semantic than the original version.

If we ended up deciding to go with Nicholas' proposal, I'd at least suggest 
that `.execute()` on a not-yet-loaded script should not throw an error, but 
should just remove/unset the `preload` flag, such that the script will just 
execute as normal when it finishes loading.

Also, I'd like someone (with better knowledge than I, perhaps Henri?) to 
consider/comment on the implications of Nicholas' statement that 
`.execute()` must be synchronous. I recall from the "async=false" 
discussions that there were several wrinkles with injected scripts executing 
synchronously (something to do with jQuery and their global Eval). We should 
definitely verify that this part of his proposal isn't setting us up for the 
same landmines that the "async=false" process had to tip-toe around.

For instance, if I call `.execute()` on a script element that is loaded and 
ready, and it's going to execute synchronously, what happens if the script 
logic itself calls other synchronous `.execute()` calls? And is the script's 
"onload" event (which fires after execution) also synchronous? I can see 
this leading to some difficult race conditions relating to how script 
loaders have to do "cleanup" (to prevent memory-leaks) by unsetting 
properties on script elements, etc.


--Kyle