[whatwg] Async scripts

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
[1]? 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>
<html>
  <head>
    <title>...</title>
    <script src="make-tables-sortable.js"></script>
    <script src="analytics.js" async></script>
  </head>
  <body>...</body>
</html>

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.

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?

[1] http://www.whatwg.org/specs/web-apps/current-work/?slow-browser#when-a-script-completes-loading

/ Jonas

Received on Wednesday, 30 September 2009 01:36:34 UTC