Re: Executing script-inserted external scripts in insertion order

> "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:42:51 UTC