[whatwg] comments on SCRIPT ASYNC and DEFER

[Steve Souders]

I have some comments and questions about the ASYNC and DEFER attributes 
of the SCRIPT tag based on reading this document:
http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html 
<http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#script>

1. "If neither attribute is present, then the script is fetched and 
executed immediately, before the user agent continues parsing the page."
     Thankfully, newer browsers are downloading scripts in parallel with 
other resources. I presume the way this is done is they launch a request 
for a script and continue to do "speculative" parsing looking for other 
resources (images, stylesheets, other scripts, etc.) and launch those 
requests. But this nice feature seems to be in conflict with the above 
text because the browser continues parsing (albeit speculatively) before 
the script is executed. It would be good to mention this optional 
behavior here, something along the lines of browsers may want to do 
speculative parsing, but shouldn't create DOM elements, etc. - only 
kickoff HTTP requests.

2. "If one or both of the defer and async attributes are specified, the 
src attribute must also be specified."
     It should be possible to specify DEFER without a SRC. The use case 
is a page that has a sequence of SCRIPTs (with and without a SRC 
attribute) all of which need to execute in order, but should do so 
without blocking the parser. This happens a lot with ads, widgets, and 
analytics. A workaround is to use callbacks to daisy-chain the calling 
sequence, but the complexity will lead most 3rd party snippet providers 
to default to a normal SCRIPT tag (without DEFER or ASYNC) resulting in 
blocking the parser and slow pages. It's especially annoying for web 
site owners to have 3rd party content slowing down their pages and 
blocking the content they've created.
     This appears to be a recent change perhaps prompted by Jonas 
Sicking's comments that Mozilla found many web sites that specified 
DEFER without a SRC and then called document.write (which pretty clearly 
indicates the developer didn't mean to specify DEFER). If that's the 
motivation for this restriction, we need to either find an alternative 
syntax or go ahead and allow DEFER without SRC. Finding an alternative 
is the worse alternative (DEFER has the exact behavior we want, so 
creating something with a different name that behaves just like DEFER is 
confusing). If we do move forward with allowing DEFER without SRC, then 
we need to specify what happens if it contains document.write so that 
the entire document isn't overwritten. (I believe this is addressed in 
section 3.5.) There's no good way to make DEFER do what it should and 
have those pages who are using DEFER incorrectly work the way they do 
now. With this path, at least those pages will have their content appear 
at the bottom and not wipe out the entire page.

3. "[the 'parser-inserted' state] is set by the HTML parser and is used 
to handle document.write() calls."
     In what way is this used to handle document.write() calls? Is it 
for handling additional SCRIPTs added via document.write, or to make 
document.write itself have different behavior? The answer should be 
added to the spec somewhere. I searched for .write in this document and 
didn't find an explanation.

4. "If the element has a src attribute, [snip] the specified resource 
must then be fetched, from the origin of the element's Document."
     If the script has DEFER, the request should not start until after 
parsing is finished. Starting it earlier could block other 
(non-deferred) requests due to a connection limit or limited bandwidth.

5. I don't see any rules for the order of executing scripts added to the 
"list of scripts that will execute when the document has finished 
parsing" and the "list of scripts that will execute as soon as 
possible". DEFER scripts should execute in the order they appear in the 
list. ASYNC scripts should be executed as soon as the response is received.

Thanks.

-Steve


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100208/db703b93/attachment.htm>