[whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

Earlier feedback on this list was that people didn't want to define readyState or onreadystatechange for script elements, which is why I changed my proposal the way that I did. Unless people's opinions have changed on that, I'm not sure why we're still talking about a readyState-based approach (and if it has changed, why not talk about my original proposal as well?). I also removed execute() for the same reason, the general feedback seemed to be that it introduced complexity even though I thought it was a bit more explicit.

You may be correct in that people may never want to set preload to false. You'll note that I put in my proposal that an alternate approach would be for preload to be set to true by default. This would allow even easier feature detection:

if (script.preload){
    //do the preload way
}

So if browsers want that to be the default, this would act as a flag indicating that the new functionality is available.

I think changing the behavior of dynamic script elements to match IE's isn't a bad idea, but we need at least two additional things:

1) A definitive way to determine that this behavior is present (earlier in this thread, people seemed to agree that an explicit feature detect was important)
2) An event that allows us to know when the script is downloaded and ready for execution

In any case, I don't believe readyState/onreadystatechange fulfills both of those.


-N

________________________________
From: Glenn Maynard [mailto:glenn at zewt.org]
Sent: Monday, February 14, 2011 1:37 AM
To: Kyle Simpson
Cc: Nicholas Zakas; whatwg at lists.whatwg.org; Nicholas C. Zakas; Will Alexander; Steve Souders
Subject: Re: [whatwg] Proposal for separating script downloads and execution

On Sun, Feb 13, 2011 at 11:09 PM, Kyle Simpson <getify at gmail.com<mailto:getify at gmail.com>> wrote:
You seem to suggest this is a bad thing. I actually think it's a good thing that we're keeping script execution as much as possible in the existing architecture. There's lots of different reasons why the queues and behavior are set up the way they are, and I can say that I never intended this new "add a script to DOM to execute" suggestion was meant to imply some entirely different "the browser must execute this now or else" kind of model. That's a much more complicated road to go down, and one which I think we'll likely derail either of the two main proposals.

I was responding to Nicholas's change, since based on his example code I'm pretty sure he expected it to be synchronous.
Basically, the suggestion is that `preload` is how a web author can force the browser from its hinted "you may preload" to "you must preload". I think this has the potential for confusion. It's like saying "If I set a script element to `async`, it will definitely be asynchronous, but if I don't set it to `async`, then it may or may not be asynchronous, I'm just not sure." The same confusion would be true of "defer", "disabled", and a whole host of other attributes/properties on HTML elements that come to mind.

I don't think it's confusing, but I also don't know why anyone would want to set preload to false.

Between the readyState proposal and the current preload proposal (with no execute method), I prefer readyState.  The execute method was the critical difference between the two proposals; removing it essentially changed his proposal into a minor variation of yours.

--
Glenn Maynard