[whatwg] Proposal for separating script downloads and execution
getify at gmail.com
Thu Feb 10 15:56:49 PST 2011
>> 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
>> 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
> 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
> 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
> readyState event. If the script is already in the cache, it appears that
> does *not* fire the "loaded" readyState event. Obviously, this is quite
> unfortunate, since it means that polling would still be a necessary piece
> 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.
More information about the whatwg