[whatwg] Proposal for separating script downloads and execution

[Kyle Simpson]

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


UPDATE: IE9 RC1 came out today, and this regression is fixed. 
`readyState=loaded` does fire the `onreadystatechange` handler as expected. 
Good news for the support of `readyState` proposal, I think.


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

Turns out I was completely wrong on this. `readyState=loaded` fires fine 
with cached items. My test code has a race-condition in it that was masking 
the correct behavior.

So, at this point, I can verify (at least in my tests), that `readyState` 
works fine (without polling) in at least IE6-IE9. This means polling is not 
necessary to support that functionality in IE. Good news on both fronts.


--Kyle