[whatwg] comments on SCRIPT ASYNC and DEFER
Steve Souders
steve at souders.org
Mon Feb 8 13:54:03 PST 2010
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-0002.htm>
More information about the whatwg
mailing list