- From: <bugzilla@jessica.w3.org>
- Date: Thu, 21 Feb 2013 16:15:29 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21074 Bug ID: 21074 Summary: Need ability to load scripts without blocking onload Classification: Unclassified Product: HTML WG Version: unspecified Hardware: All URL: http://www.lognormal.com/blog/2012/12/12/the-script-lo ader-pattern/ OS: All Status: NEW Severity: enhancement Priority: P2 Component: HTML5 spec Assignee: robin@w3.org Reporter: philip.tellis@gmail.com QA Contact: public-html-bugzilla@w3.org CC: mike@w3.org, public-html-admin@w3.org, public-html-wg-issue-tracking@w3.org The URL describes this in detail, but I'll describe a summary here. Current Situation: We include scripts in an HTML document using the <script> tag: <script src="script-url" type="text/javascript"></script> In this case, parsing and rendering of the document blocks until the script has been downloaded, parsed and executed since the script might change the document using document.write. If the script does not use document.write, the developer can use the async attribute to tell the browser that it can continue loading, parsing and rendering the page in parallel with the downloading, parsing and execution of the script: <script async src="script-url" type="text/javascript"></script> However, this script will still block the onload event (not clear in the spec, but all implementations appear to do this). Required Enhancement: We should either add a new attribute: "nonblocking", or add a new attribute value for the async attribute: async="nonblocking". It would work as follows: <script async="nonblocking" src="script-url" type="text/javascript"></script> This provides a hint to the user agent that it should start downloading, parsing and executing as soon as possible but it should not block the onload event (or any other event) of the containing document waiting for this script to download, parse and execute. This should also be usable in dynamically injected script nodes. User Agents that treat async as a boolean attribute will fall back to the current model. Why do we need this? Third party scripts are included in websites all over the Web. If one of these third party servers becomes unresponsive (eg: DNS failure, host timeout, etc.), this will block the onload event on all sites that include the third party script even if the async attribute is used. Since many sites perform some amount of page setup tasks in the onload event handler, this could block these tasks indefinitely depending on timeout values. The only option now available is the iframe hack described in the attached URL. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 21 February 2013 16:15:35 UTC