- From: Getify <getify@gmail.com>
- Date: Thu, 14 Oct 2010 06:44:00 -0500
- To: "public html" <public-html@w3.org>
> "Async makes external scripts execute as soon as they've been downloaded without blocking other scripts form executing while the async script is downloading in contrast to the normal behavior of waiting until earlier external scripts have been downloaded and executed and blocking subsequent scripts from executing." > > OK, it's a bit long for one sentence. How about: "Async makes external scripts execute as soon as possible when downloaded, without any dependence or effect on any other scripts or page resources, in contrast to the normal behavior of external scripts blocking execution such that they execute in the order requested." > I consider it rather surprising that this is the case--that is, I think > its surprising and counter-intuitive that the state of the async property > currently has no effect on script-inserted external scripts when it does > have an effect on parser-inserted external scripts. Yes, as I said in my very first response in this thread, I believe there's a logical and well-placed symmetry to making `async` control this execution-blocking behavior for both parser-inserted and script-inserted external scripts. It's very easy to defend that as designed and intended behavior, whereas the way spec reads currently, it's less obvious and defendable why `async` only works for parser-inserted scripts. > Note that in Firefox 3.6, the state of the async property does have an > effect on both script-inserted external scripts and on parser-inserted > external scripts. In both cases, async=false is the default and makes the > external scripts maintain order and async=true opts into the executing as > soon as downloaded without blocking subsequent scripts. I understand the FF 3.6 behavior that is undesirable is the side effects (blocking) between an external script-inserted script and an inline script (hence the change that motivated this whole thread). I agree this side-effect should be removed. As a consequence, I also agree that parser-inserted scripts should be in a separate queue from script-inserted scripts, and moreover, script-inserted inline scripts should execute immediately independent of either queue. But other than those behavioral changes to the queues, with respect *only* to the `async` behavior controlling order-enforceability (only within each 'queue', respectively), and the default value of `false` , we are basically suggesting spec should match the way FF 3.6 currently works, correct? >> > * The default would go the same way (async=false) for both >> > script-created and parser-created scripts. >> > >> > The big question is if we can get to interop via this route. That >> > depends on whether IE and WebKit are willing to change their default >> > behavior for script-inserted external non-async scripts. Are they? In my mind, and perhaps I'm missing an important detail, but I think we are asking two distinct things of IE/Webkit/Chrome: 1. Support the `async` property on *both* parser-inserted and script-inserted external scripts, as it pertains to the "elevator pitch" behavior above, regarding ordered execution enforcement. 2. Set the default of this property (and thus the behavior) to `false` for *both* parser-inserted and script-inserted external scripts. The reason I separate the two in that way is because I think we can still achieve our goals even if IE/Webkit/Chrome only do (1) but insist on the opposite [async=true] for either type of script in (2). IE/Webkit/Chrome already have the `async=true` behavior for script-inserted scripts, they just need to extend it to parser-inserted scripts that are found to have an `async=true` attribute on them. They also currently have `async=false` behavior for parser-inserted scripts, so they just need to extend it to script-inserted scripts that have `async=false` on them. But whether they agree on which value should be default, and in which case (or 'queue') is, in my mind, a separate story. I think the discussion has shown that there are some valid arguments for both sides of that coin. While it may seem counter-intuitive for the default to be different for parser-inserted versus script-inserted, I can see why having the two defaults be separate and opposite (that is, `async=true` for script-inserted) might be defendable for compatibility with existing content. Don't get me wrong, I think having the spec define the default value for each case would be a *very desirable* thing (and I think it'd be great if we could agree what the default should be in each of the cases). But if the decision of which is default when becomes a hanging point, I think all the important use-cases can still be served if we drop definition of a default value for `async` and leave it to browsers to decide which default makes sense under which circumstances. Certainly, web authors (like myself) who are going to use either or both behaviors can simply take to a pattern of always specifying the value to what we want it to be, thereby covering up any inconsistencies between default values across different browser implementations. The important part is that both behaviors (ordered and un-ordered) be accessible to opt-into for *both* parser-inserted and script-inserted scripts. Side note: I think it's also important for spec to be very clear on (and for IE/Webkit/Chrome to strongly consider) the separate queues concept and more specifically on how inline scripts shouldn't be in the queue (at least for script-inserted), that way no other browser gets the undesirable behavior that FF3.6 was trying to change to eliminate. Talking about the separate queues and what goes in each queue might be considered a little too specific of an implementation detail for spec (although I think there's precedence for it), but in this case, I think the nuances of the various side-effects are important to spell out so we keep ourselves away from the quirky behaviors that end up harming various web content niche use-cases (like jQuery's global Eval, for instance). --Kyle
Received on Thursday, 14 October 2010 11:44:30 UTC