Does anyone know of any browsers actually planning to support the async attribute? From the quick survey I've done, it doesn't appear they are. Anyone have any thoughts on what's holding them back?<div><br></div>
<div>-Brian<br><div><br></div><div><br><br><div class="gmail_quote">On Wed, Sep 30, 2009 at 9:59 PM, Darin Fisher <span dir="ltr"><<a href="mailto:darin@chromium.org">darin@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div><div></div><div class="h5">On Wed, Sep 30, 2009 at 1:36 AM, Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There's two things that I don't understand about the 'async' attribute<br>
on <script> elements:<br>
<br>
First of all, why is the parser responsible for executing scripts on<br>
the "list of scripts that will execute asynchronously", as defined by<br>
[1]? It would seem simpler to always perform the steps defined further<br>
down, no matter if the document is still being parsed or not. This is<br>
mostly an editorial issue, but actually seems to make a slight<br>
behavioral difference. Right now if a document contains two async<br>
scripts, the tokenizer must always run one step between the execution<br>
of the two. I.e. This doesn't seem like a particularly desirable, nor<br>
testable, behavior. It's also really painful to implement if the<br>
tokenizer is running on a separate thread. Same thing applies to the<br>
"list of scripts that will execute as soon as possible".<br>
<br>
Second, why are async scripts forced to run in the order they appear<br>
in the markup? I thought the whole idea of the async attribute was to<br>
run the scripts as soon as possible, while still not blocking parsing.<br>
This leads to weird situations like if a document contains the<br>
following markup:<br>
<br>
<!DOCTYPE html><br>
<html><br>
<head><br>
<title>...</title><br>
<script src="make-tables-sortable.js"></script><br>
<script src="analytics.js" async></script><br>
</head><br>
<body>...</body><br>
</html><br>
<br>
In this example, if the first script is changed from being a "normal"<br>
script (as above), to being a async script, that could lead to the<br>
analytics script actually executing later.<br></blockquote><div><br></div></div></div><div>Did you perhaps mean to say "if both scripts are changed to being async"?</div><div><br>If not, then I'm confused because you prefaced this example with "why are async</div>
<div class="im">
<div>scripts forced to run in the order they appear in the markup?"</div><div><br></div></div><div>I agree that normal scripts should not be deferred behind async scripts that</div><div>happen to be listed before the normal scripts. I don't think that is the intent</div>
<div>of the async script spec.</div><div><br></div><font color="#888888"><div>-Darin</div></font><div class="im"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I thought the purpose of the async attribute was to avoid people<br>
having to do nasty DOM hacks in order to increase pageload<br>
performance, but this makes it seem like such hacks are still needed.<br>
<br>
What is the use case for the current behavior?<br>
<br>
[1] <a href="http://www.whatwg.org/specs/web-apps/current-work/?slow-browser#when-a-script-completes-loading" target="_blank">http://www.whatwg.org/specs/web-apps/current-work/?slow-browser#when-a-script-completes-loading</a><br>
<font color="#888888"><br>
/ Jonas<br>
</font></blockquote></div></div><br>
</blockquote></div><br></div></div>