[whatwg] Proposal for separating script downloads and execution

Tue Feb 8 01:28:15 PST 2011

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.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/