[whatwg] Proposal for separating script downloads and execution

[Kyle Simpson]

> This change wasn't mentioned here, and introduces a lot of problems.
>
> - <script onerror> is only dispatched for fetch errors, not syntax errors, 
> which makes error detection harder.
> - If the called script throws an exception, the synchronous execute() 
> model allows the exception to be raised by execute().  With this model, 
> they go straight to the browser and they're much harder to detect.

I can see why having `onerror` also fire for parsing (or even run-time) 
errors might be helpful, but I'd consider that orthagonal to this 
discussion. We don't have that now, so it's not necessarily a short-coming 
that this proposal doesn't get into the complications of that discussion. 
This proposal process should, I believe, be as simple and straightforward as 
possible, and not some comprehensive review/change of all of script's 
functional characteristics.

We could (and probably should) consider that kind of thing in a separate 
proposal. There are many things about the script element's events which are 
quirky and could benefit from some further clarification from the spec. This 
is part of my overall goal in addressing the various short-fallings, but I 
don't think we need to necessarily bog down this proposal with that 
additional line of argument.

In my opinion, especially because both main proposals now seem to rely on 
the normal browser script execution model, with a script element simply 
being added to the DOM, we shouldn't be concerned that some additional 
potential error checking that `execute()` might have given us is now gone... 
rather, we should just consider that as future discussion that needs to 
happen separate from this thread/proposal.


> - The scripts won't be executed immediately if there are already any 
> scripts on the "list of scripts that will execute in order as soon as 
> possible"; they'll be deferred until it's their turn.

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.


>> Moreover, the strict reading of Nicholas' proposal is that a browser 
>> should not preload a script resource if the `preload` property is not set 
>> to `true`. This has two implications:
>
> Maybe this was changed since you sent this mail, but: "When preload is 
> false, the user agent may download and execute the external script 
> according to its normal behavior."  Setting preload to true requires 
> preloading, but leaving it at false should change nothing.

Perhaps on my initial reading I missed that section (I apologize if so), or 
perhaps Nicholas added it later. Either way, it presents us with an 
interesting situation, one which I'm neither sure I support nor disagree 
with at the moment.

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.

The strong precedent is that such boolean attributes convey the semantics of 
binary (on or off), not (on or maybe on). That's a strange new semantic 
precedent to introduce.

If we were to go the route of Nicholas' proposal, I think the name should be 
"forcePreload" to signify that setting it to false doesn't mean "don't 
preload", it simply means "don’t force preload".


> [1] Note that FF3.6 does execute a script immediately when it's inserted 
> into the document, if the script is cached.  I'm pretty sure that's a bug. 
> Whether due to a bugfix or simply being masked due to changes in cache 
> behavior, it doesn't seem to happen in FF4.

I'm almost positive that what you've identified is what led Firefox to 
address the whole script order thing in the first place for FF4, which is 
what led to the cascade of changes, like "async=false", etc. IIRC, there was 
some bug with jQuery's globalEval that preciptated them addressing the bug 
you point out. Check the Mozilla bug tracker for more info.




--Kyle