[whatwg] Proposal for separating script downloads and execution

Will Alexander serverherder+whatwg at gmail.com
Tue Feb 15 11:37:39 PST 2011


While they are converging, I think the first proposal is simpler,
defines a much more generic interface with applicability beyond script
elements, provides a mechanism for opting into or out of the behavior,
and will lead to cleaner javascript and, unlike readyState, does not
introduce compatibility issues.

Although I'm not aware of anyone wrapping a 250KB style-sheet in
comments, the pre-loading interface could seemingly be applied to any
number of elements.  Nicholas' original e-mail referenced a blog post
by Stoyan Stefanov which details a way to pre-fetch both scripts and
stylesheets.

Requiring authors opt-into the behavior seems best at least in the
short term and readyState does not provide this mechanism.  Making RPC
or Ad calls can require disabling this functionality in IE and create
quite a kluge. (1)

The pre-load proposal will encourage separating that logic into (at
least) two functions, leading to javascript that is easier to manage
and more clearly communicates its intent.  OTOH, with readystate, the
tendency will be to add logic for both "preload" and "onload" into a
single handler, despite the fact they completely different reasons to
change.  While certainly not the spec's problem, **anything** that
leads to better ES is a win.

Most concerning, however, is that adopting readyState will undoubtedly
create compatibility issues.   It's quite common to registerfor both
onload and onreadystatechange, testing for the readyState property
within the handler.  Code like this will execute callback() twice.

    script.onload= script.onreadystatechange= function(){
              if(
                    this.readyState  &&
                    this.readyState != 'loaded' &&
                    this.readyState != 'complete'
                ) return;

             callback();
    }
If the spec decides to deviate from IE's behavior (2), and requires
readyState transition to both loaded and complete, it could fire three
times. Specifying IE's  behavior (which most will admit seems
non-intuitive) would also seem to be difficult.  Even though there is
an existing precedent in the spec and something of a "reference"
implementation, dragons lurk.

Will

(1)  I do think it's wise to give user-agents the latitude to decide
the default behavior that works best for their audience.  Instead of
defining the default value for preload, should the value reflect
agent-specific default?  IOW, if IE implements this, should its
default preload value be "true"?

(2) A cached script will have its readyState set to "loaded" when the
src attribute is assigned, but will not fire the readystatechange
event.  Attaching the script triggers synchronous execution, fires
readystatechange, but does NOT set the readystate to "complete".


On Sun, Feb 13, 2011 at 6:44 PM, Kyle Simpson <getify at gmail.com> wrote:
> 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
>


More information about the whatwg mailing list