- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 1 Oct 2009 01:07:27 -0700
On Wed, Sep 30, 2009 at 10:14 PM, Darin Fisher <darin at chromium.org> wrote: > On Wed, Sep 30, 2009 at 9:59 PM, Darin Fisher <darin at chromium.org> wrote: >> >> 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 >>> [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. >> >> 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 >> async >> 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 >> intent >> of the async script spec. >> -Darin > > D'oh, ignore me. ?I overlooked the "async" attribute on the second <script> > tag. > Anyways, I agree with you. ?Forcing the scripts to run in the order they are > listed > seems to defeat the purpose of the async attribute. > I'm guessing it was spec'd this way to minimize problems that could occur if > there > were any dependencies between the scripts. That was my guess too. However async scripts already "race" with non-async scripts, so it seems like you're already having to be careful with what you put in your async scripts. Additionally the spec has created another mechanism which *does* allow scripts to run in arbitrary order as soon as they load. You basically create one <script> that then create other script elements using the DOM. It's just a pain to use that method. I'll be writing a separate post about that one later. / Jonas
Received on Thursday, 1 October 2009 01:07:27 UTC