Re: Executing script-inserted external scripts in insertion order

Getify wrote:
> > 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?

Yes. (Though parser-inserted non-async, non-defer scripts don't actually go into a *queue*--only to a single-node holder--since there can be only *one* parser-blocking script at a time.)

> >> >  * 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:

Indeed.

> 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).

I'm hoping the (1) part can be agreed to as non-controversial.

>From my point of view, the debate at this point is which way the default should go for point (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.

Yes.

> But whether they agree on which value should be default, and in which
> case
> (or 'queue') is, in my mind, a separate story.

Indeed.

> 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.

Do you mean for compatibility with existing IE/WebKit behavior? For compatibility with existing content (i.e. existing order-dependent LABjs and RequireJS deployments that sniff Gecko and Opera), one would want async=false as the default.

> 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.

If different browsers end up having a different default after the situation has stabilized, we will have failed to arrive at interop.

> The important part is that both behaviors (ordered and un-ordered) be
> accessible to opt-into for *both* parser-inserted and script-inserted
> scripts.

I think it's also important for the default to become the same across browsers in due course.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Thursday, 14 October 2010 13:20:05 UTC