- From: <bugzilla@jessica.w3.org>
- Date: Wed, 29 Dec 2010 18:27:37 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 --- Comment #4 from Kyle Simpson <w3c@getify.myspamkiller.com> 2010-12-29 18:27:36 UTC --- To explain further the motivations behind this proposal (and Mozilla's implementation of it): With respect to the underlying functionality being requested: Scripts that are added as script tags in the HTML markup have the ability to choose if the author wants them to execute in insertion-order or in "as soon as possible" order. This is of course the `async` attribute. However, it is strange and frustrating (as described above) that script elements which are dynamically added to the DOM do *not* have the ability to choose between these two ordering modes. The functionality request is to make the "async" feature symmetrical between parser-inserted scripts and script-inserted scripts. That is, an author should be able to set `true` or `false` on the `async` property on a script-inserted script element just like they can add or withhold the `async` attribute in markup for parser-inserted script elements. -------- With respect to the `async` property default value being `true` instead of `false`: According to the way the spec currently reads, a spec-conforming browser should treat a script-inserted script element in such a way that it executes "as soon as possible". This means that a script-inserted script element currently behaves in most ways very similar to a parser-inserted script element that the `async` attribute set on it. It therefore makes some sense (again, consistency and symmetry wise) to default the script-inserted script element's `async` property to `true` to reflect this behavioral relationship. Moreover, it's EXTREMELY important that the addition in browsers and the spec be done in a way that this augmented behavior (selecting ordering behavior on script-inserted script elements by setting the `async` property) be **feature-testable**. Since currently all browsers that implement the "async" functionality default the `async` property on script-inserted script elements to `false`, I suggested that changing the default to be `true` would kill two birds with one stone: it would bring the `async` property more into semantic line with the current spec'd behavior for script-inserted script elements, but it would also provide a reasonable feature-test for the new behavior. By creating a dynamic script element and examining the default value of the `async` property, an author can know if they are in a browser implementing this augmented behavior or not. var async_ordering = (document.createElement("script").async === true); In fact, now that Mozilla did this with FF4b8, and LABjs updated to do that feature-test, it proves the viability of that approach because LABjs now works just fine in both FF4b8 with the proposal implementation, and in older FF's (and other browsers) without the proposal implemented. @Jonas- If we switched the spec AND preserved the default value and behavior as `false` (aka, insertion-ordered), how could we feature-test for this? -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 29 December 2010 18:27:41 UTC