- 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