- From: Kyle Simpson <getify@gmail.com>
- Date: Sun, 13 Feb 2011 22:09:41 -0600
> 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
Received on Sunday, 13 February 2011 20:09:41 UTC