[whatwg] Proposal for separating script downloads and execution

[Kyle Simpson]

I've compiled a WHATWG Wiki page detailing both Nicholas' most recent (and 
simplified) proposal (v2.1), as well as mine:

http://wiki.whatwg.org/wiki/Script_Execution_Order_Control

In essence, the two are somewhat converging, though are still distinct in 
important ways. Nicholas's proposal now includes relying on DOM appending to 
execute a script (instead of using a new `execute()` method), in agreement 
with my proposal.

But he relies on a new property `preload` to signal that preloading should 
happen before DOM append (instead of how it automatically happens in IE and 
in the Specification, currently). He also specifies a new event `onpreload`, 
whereas my proposal uses the existing precedent of the `readyState` property 
and `onreadystatechange` event firing.

I've stated before in this thread several reasons why I still prefer my 
proposal to the one Nicholas is advocating. I won't repeat those. But, while 
his changes and simplifications have greatly improved his solution to the 
point where many of my original concerns are almost moot, there's one 
fundamental point which I cannot move past.

My proposal seeks to codify what IE already does, and what's already a 
suggestion in the Specification. Since IE is the more slower-moving of the 
various browser vendors, I'm attempting to codify a solution that is more 
likely to see adoption "soon". If we specify anything that requires changes 
by IE, while those changes are of course possible, the timing of them (in 
relation to IE9 RC -- feature-complete -- being recently released) will be 
in jeopardy of not happening any time "soon" (until at least IE9.1 or IE10, 
which could be a year or more off from now). My proposal accepts IE's 
current behavior without change, which in general may give us a quicker path 
to full implementation in all browsers.

Moreover, the strict reading of Nicholas' proposal is that a browser should 
not preload a script resource if the `preload` property is not set to 
`true`. This has two implications:

1. It contradicts the existing Specification performance-suggestion, which 
would of course need to be amended to fit; AND

2. More importantly, it requires that IE, to adhere to the strict behavior 
wording, must *change* their existing automatic pre-fetching, so that it not 
occur unless `preload` is true. Requiring IE to change their existing 
behavior in this way is likely to lead to one of two outcomes:

   a. IE agrees to pin the behavior on the `preload` property, but to reduce 
backwards-compat with their browser community's content, they insist on the 
default behavior being `preload=true`. If this happens, the spec should 
seriously consider aligning with that, because having different default 
behaviors in different browsers will only complicate the situation, where 
with this proposal we're trying to remove hacks and complication for simpler 
functionality.

   b. Or, IE will refuse to change their behavior to be dependent on 
`preload`, citing fears of backwards-compat problems (loss of performance), 
in which case we have failed to achieve compat cross-browser (a very 
important and stated goal of these proceedings).


Specifically related to (2), I would say that, barring some further input 
from the IE team to contradict my observations and assumptions, the more 
solid path forward to full cross-browser compat is to standardize on the 
existing IE behavior as my proposal suggests.



--Kyle