[whatwg] Proposal for separating script downloads and execution
Kyle Simpson
getify at gmail.com
Sun Feb 13 15:44:53 PST 2011
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
More information about the whatwg
mailing list