[whatwg] Proposal for separating script downloads and execution

[Kyle Simpson]

?> I think we should do the readyState thing and put a note in the spec 
saying that implementors should be polite to authors and not implement the 
readyState property until they also implement the behavior that setting .src 
on a not-in-tree node starts the HTTP fetch (in order to make the behavior 
feature detectable from JS).
>
> Adopting the readyState / early .src assignment mechanism has these 
> benefits over the proposed alternative:
> * Already (reportedly; I didn't test) work in IE. Always a plus over 
> making up some new stuff.
> * Authors already have to deal with IE, so the question of opting in 
> doesn't arise.
> * Sites already have to work when scripts haven't been fetched yet and 
> when the scripts are already in the HTTP cache. Thus, starting the fetch 
> earlier than before shouldn't cause breakage since the "worst" case is 
> that the observable behavior becomes similar to the script already being 
> in cache by the time the node is attached to the tree.
> * img elements have started fetches upon .src setting since almost 
> forever, so making scripts do the same makes the platform more 
> self-consistent.
> * noexecute when used in markup has a particularly bad degradation story.


**Very much** agree with Henri's assessment here.


> I agree with Henri's analysis. Opera already has readyState (with value
> always being 'loaded'), but we'd be careful to fix script prefetching and
> readyState 'uninitialized' at the same time.

Awesome, that's very helpful to have cooperation from Opera like that! Thank 
you. :)


> That is only the case if there is a readystatechange event. Is that so?

Yes, IE has had the `readystatechange` event on script elements for a very 
long time (pre IE6 at least). However, as noted below in just a moment, it's 
not quite as reliable as one would hope it would be. But it *is* there, and 
I think makes a good candidate reference implementation (sans the 
quirks/bugs about to be discussed) for what the HTML specification could 
adopt as requirement.


> Testing this shows that IE9 doesn't fire a progress event for the 
> transition that is of interest for the use case. That is, when the script 
> transitions to "loaded", there's no event. Once the script has been 
> evaluated, there is a (rather useless) progress event for the transition 
> to "complete". The interesting transition to "loaded" can only be observed 
> by polling. Sigh. :-(
>
> Demo: http://hsivonen.iki.fi/test/moz/script-readystate.html

You're correct about this not working in IE9b. But it would seem that it's a 
regression, as I just checked in IE6-8, and it does indeed fire the 
`onreadystatechange` event on the "loaded" state. I'm going to file a bug in 
the IE9 feedback system to ask them to address that regression.

Here's my test: http://test.getify.com/ie-script-readystate/

*HOWEVER*, in IE6-8 (and I would assume IE9 once they address that 
regression), there's still a wrinkle with being able to rely on the "loaded" 
readyState event. If the script is already in the cache, it appears that IE 
does *not* fire the "loaded" readyState event. Obviously, this is quite 
unfortunate, since it means that polling would still be a necessary piece of 
the puzzle for IE.

But, it can be used as a fallback along with the onreadystatechange handler, 
with a higher timeout like 100ms, and thus degrade nicely between IE and 
other browsers (if they eventually implement this feature... correctly).

Also, I am going to file a separate bug with IE9 Feedback to ask them to 
fire the "loaded" event when loading from cache. Perhaps they'll fix both 
the regression and this bug all in one fell swoop. I can dream, can't I?


> Is there any reason to believe that sites set .src on scripts they don't 
> intend to have fetched?

There's some reason to believe that there could be speculative fetching in 
some sites apps (obviously IE only), where the fetching happens but the user 
never activates some part of the page (like a tab or widget) which needs the 
script, and so in some cases where sites have advanced techniques like this, 
there may be some "waste". But I'd suggest that in almost all cases, the 
wasted load is the "fault" of the web author for being speculative rather 
than the fault of the browser. It's clearly an advanced technique that 
requires intentional opt-in. And since it only works in IE at the moment, I 
doubt there's very many sites doing it.



--Kyle