[whatwg] Proposal for separating script downloads and execution

[Glenn Maynard]

On Sun, Feb 13, 2011 at 11:09 PM, Kyle Simpson <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