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:gl...@zewt.org]
Sent: Monday, February 14, 2011 1:37 AM
To: Kyle Simpson
Cc: Nicholas Zakas; whatwg@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
<get...@gmail.com<mailto:get...@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
