On 2/23/11 9:14 AM, Kyle Simpson wrote:
The goal (from my perspective) is to come up with the simplest proposal that serves the use-cases. Simplest being defined in this particular situation as the least amount of change to the spec, AND the least amount of change to the browser that has by far the slowest release cycle (IE).
That last part is an important point, yes.
a) is execute() sync or async? what does this imply about if the script being executed itself calls execute() on other script elements, and so on?
Fair enough. Seems to me that execute() should act just like inserting an inline script into the DOM does right now. Browsers already have to handle that; they could just reuse this code.
b) what does it imply about whether/when the event handler(s) would be fired? If it's synchronous, are the event handlers also synchronous or are they async? Are they fired before or after the execute() actually does the executing of the script element?
Which event handlers?
d) what are the semantics of if you call execute() on a script element before it has finished preloading
Good question, yes.
e) what happens if a script's .text is modified before execute() is called? What if a script element is cloned before execute() is called? What if it's cloned after execute() is called?
Also good questions.
3. If in the future we want to also support preloading of other resources, like stylesheets for instance
Preloading of stylesheets is already supported in at least Gecko. Just mark them as disabled (or an alternate stylesheet not in the main set, which is the same thing in effect) and the sheet will be loaded+parsed but not applied. Which is presumably what you mean by stylesheet preloading?
Again, I think the spirit we all share is to find the simplest proposal that gets the job done, and introducing a new .execute() concept raised more questions than it purported to solve.
OK, fair.
I strongly disagree with this characterization, based solely on the fact that the wording of the current spec already says to do exactly as I'm proposing. That's not a "compatibility hack", that's further standardizing the wisdom that the spec writers already thought through and codified.
I think you're overestimating the "wisdom" and "thought through", but I'll let hixie respond to that. It's just as likely that he just specced the IE behavior as optional because IE was already doing it and wasn't planning to change, and moved on.
-Boris
