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



Reply via email to