[whatwg] Proposal for separating script downloads and

[Boris Zbarsky]

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