- From: Glenn Maynard <glenn@zewt.org>
- Date: Mon, 14 Feb 2011 01:36:35 -0500
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
Received on Sunday, 13 February 2011 22:36:35 UTC