Re: [whatwg] comments on SCRIPT ASYNC and DEFER
On Feb 8, 2010, at 23:54, Steve Souders wrote: 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. FWIW, the HTML5 parser in Gecko (not on by default yet) does more than just kicks off HTTP requests. However, what it does isn't supposed to be detectable by author-supplied scripts. 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. As I understand it, starting the request early is the whole point of 'defer'. Otherwise, the author could put those scripts at the end of the page. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] comments on SCRIPT ASYNC and DEFER
In the current text, it says must then be fetched. In my suggestion I say should not start until after parsing. Saying should instead of must leaves the opening for browsers that feel they can fetch immediately without negatively impacting performance. -Steve On 2/9/2010 6:39 PM, Boris Zbarsky wrote: On 2/8/10 4:54 PM, Steve Souders wrote: 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. Shouldn't this be left up to a UA? I can see a UA with high enough connection limits being willing to use some small number of those connections for deferred scripts even before parsing is done. The alternative might end up being for the network to be completely idle while a bunch of parsing happens followed by a flurry of deferred script loading activity -Boris
Re: [whatwg] comments on SCRIPT ASYNC and DEFER
Two common scenarios where scripts aren't put at the bottom: - Having talked to web devs across hundreds of companies it's often the case that they control a certain section of the page. Inserting content outside of that section requires changing so much infrastructure, they skip the optimization. - 3rd parties have no control over where their snippet is placed in the content owner's page. Providing a snippet that contains DEFER will guarantee they don't block the main page's content. -Steve On 2/10/2010 1:31 AM, Henri Sivonen wrote: On Feb 8, 2010, at 23:54, Steve Souders wrote: 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. FWIW, the HTML5 parser in Gecko (not on by default yet) does more than just kicks off HTTP requests. However, what it does isn't supposed to be detectable by author-supplied scripts. 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. As I understand it, starting the request early is the whole point of 'defer'. Otherwise, the author could put those scripts at the end of the page.
Re: [whatwg] comments on SCRIPT ASYNC and DEFER
On Wed, Feb 10, 2010 at 10:49 AM, Steve Souders wha...@souders.org wrote: Two common scenarios where scripts aren't put at the bottom: - Having talked to web devs across hundreds of companies it's often the case that they control a certain section of the page. Inserting content outside of that section requires changing so much infrastructure, they skip the optimization. - 3rd parties have no control over where their snippet is placed in the content owner's page. Providing a snippet that contains DEFER will guarantee they don't block the main page's content. I think there are use cases both for wanting to start fetching as soon as possible, and to start fetching at the end in order to avoid blocking. However defer is already implemented in IE and Firefox as a way to start fetching as soon as possible, but only execute at the end, so I'm reluctant to change it at this point. Instead, if the use cases are strong enough, I think we need to introduce another mechanism for delaying a script to get loaded until after the 'load' event has fired. I think it's an interesting idea to add a 'postonload' attribute to all resources, such as script, img and link rel=stylesheet (though the maybe the name could be better). / Jonas
Re: [whatwg] comments on SCRIPT ASYNC and DEFER
On 2/8/10 4:54 PM, Steve Souders wrote: 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. Shouldn't this be left up to a UA? I can see a UA with high enough connection limits being willing to use some small number of those connections for deferred scripts even before parsing is done. The alternative might end up being for the network to be completely idle while a bunch of parsing happens followed by a flurry of deferred script loading activity -Boris
