[whatwg] Async scripts
darin at chromium.org
Wed Sep 30 21:59:33 PDT 2009
On Wed, Sep 30, 2009 at 1:36 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> There's two things that I don't understand about the 'async' attribute
> on <script> elements:
> First of all, why is the parser responsible for executing scripts on
> the "list of scripts that will execute asynchronously", as defined by
> ? It would seem simpler to always perform the steps defined further
> down, no matter if the document is still being parsed or not. This is
> mostly an editorial issue, but actually seems to make a slight
> behavioral difference. Right now if a document contains two async
> scripts, the tokenizer must always run one step between the execution
> of the two. I.e. This doesn't seem like a particularly desirable, nor
> testable, behavior. It's also really painful to implement if the
> tokenizer is running on a separate thread. Same thing applies to the
> "list of scripts that will execute as soon as possible".
> Second, why are async scripts forced to run in the order they appear
> in the markup? I thought the whole idea of the async attribute was to
> run the scripts as soon as possible, while still not blocking parsing.
> This leads to weird situations like if a document contains the
> following markup:
> <!DOCTYPE html>
> <script src="make-tables-sortable.js"></script>
> <script src="analytics.js" async></script>
> In this example, if the first script is changed from being a "normal"
> script (as above), to being a async script, that could lead to the
> analytics script actually executing later.
Did you perhaps mean to say "if both scripts are changed to being async"?
If not, then I'm confused because you prefaced this example with "why are
scripts forced to run in the order they appear in the markup?"
I agree that normal scripts should not be deferred behind async scripts that
happen to be listed before the normal scripts. I don't think that is the
of the async script spec.
> I thought the purpose of the async attribute was to avoid people
> having to do nasty DOM hacks in order to increase pageload
> performance, but this makes it seem like such hacks are still needed.
> What is the use case for the current behavior?
> / Jonas
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg