- From: Will Alexander <serverherder+whatwg@gmail.com>
- Date: Tue, 15 Feb 2011 14:37:39 -0500
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 >
Received on Tuesday, 15 February 2011 11:37:39 UTC