W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2011

[whatwg] Proposal for separating script downloads and execution

From: Kyle Simpson <getify@gmail.com>
Date: Tue, 22 Feb 2011 12:50:13 -0600
Message-ID: <FEED60EE02EB4CBAB654AF2C4DD1C9FD@spartacus>
>>> 1)  If your script is no-cache, or max-age:0, does IE make a new
>>>     request for it for every<script>  element?
>>
>> For the most part this seems to be the case but there are two exceptions:
>>    a) Before a URL loads, if it's assigned to another script, only one
>> request is made.
>
> OK, that would be a violation of the HTTP caching semantics.

Can you explain how, in more detail? In practice I haven't seen IE's 
behavior be a problem, but perhaps I'm not seeing the full context of the 
issue you're concerned with.


>> IE<  9 may mitigate this to some degree by enforcing its standard
>> garbage collection rules. If only circular references to the script
>> element exist, IE will abort the network request and never fire the
>> readystatechange event.
>>
>> (function(){
>>     var s= create('script');
>>     s.src= ....
>>     s.onreadystatechange= function(){addToDom(this);};
>> })();
>
> Uh... In that situation I would expect the event handler to keep the 
> script alive until the load finishes.  Anything else is just a bug that 
> exposes GC timing to the web page.

I've said the same thing to Will before. I agree that a script having a 
circular reference to itself via the closure that's created when its handler 
is created and assigned... *should* have kept the item alive and not GC'd. I 
don't understand why IE GC's in this way.

In any case, for all intents and purposes, for someone to be using the 
"preloading" as we're suggesting (with either proposal), you'd have to keep 
around a reference to the script element anyway, so that you could later 
programmatically execute it. So, I think this GC quirk of IE would in 
practice mostly be avoided.


--Kyle

 
Received on Tuesday, 22 February 2011 10:50:13 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:31 UTC