[whatwg] Proposal for separating script downloads and execution
getify at gmail.com
Sun Feb 13 20:09:41 PST 2011
> 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
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".
>  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.
More information about the whatwg