[whatwg] Proposal for separating script downloads and execution

On Tue, 08 Feb 2011 10:28:15 +0100, Henri Sivonen <hsivonen at iki.fi> wrote:

> On Feb 4, 2011, at 03:13, Jonas Sicking wrote:
>
>> On Thu, Feb 3, 2011 at 4:45 PM, Kyle Simpson <getify at gmail.com> wrote:
>>> ?> One reason I like the noexecute proposal more than relying on
>>>>
>>>> readyState is that noexecute can be used in markup. I.e. you can do
>>>> things like:
>>>>
>>>> <html>
>>>> <head>
>>>> <script src=a.js noexecute onload="...">
>>>> <script src=b.js noexecute onload="...">
>>>> <script src=c.js noexecute onload="...">
>>>> </head>
>
> I think this would be a bad solution, because existing browsers wouldn't  
> honor noexecute, so the solution wouldn't degrade gracefully. On the  
> other hand, if the spec required browsers to start fetching external  
> scripts as soon as .src is set on script nodes that aren't in the tree,  
> the degradation behavior wouldn't be a bigger difference that the  
> difference between IE and others today.
>
>> Sure, but we'd also want to fire some event once the script has been
>> fully downloaded so that the page doesn't have to use a timer and poll
>> to figure out when the download is done.
>
> Firing a readystatechange event each time readyState changes would be  
> the most natural thing to do. Does IE already do that?
>
> On Feb 4, 2011, at 03:15, Jonas Sicking wrote:
>
>> I agree. I don't think that the readyState mechanism is particularly
>> simpler. Another nice thing about the noexecute design is that it is
>> purely opt-in, which means that you don't risk poor on already
>> existing pages.
>
> 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.

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.

-- 
Simon Pieters
Opera Software

Received on Tuesday, 8 February 2011 02:31:17 UTC