- From: Adam Barth <w3c@adambarth.com>
- Date: Sun, 17 Oct 2010 22:26:36 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: public html <public-html@w3.org>
On Sun, Oct 17, 2010 at 10:21 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > The proposal I think makes the most sense at the moment is the following, as > I understand it: > > 1) The DOM async property no longer fully reflects the "async" > attribute. This allows the property to be true even if the > attribute is not set. Setting the property also sets or removes > the attribute. Setting or removing the attribute sets the > property (to true and false respectively). > 2) When a <script> element is created via createElement, its async > property defaults to true, even though it has no "async" attribute. > 3) When a script-inserted <script> element's async property is false, > it is ordered with respect to other script-inserted <script> > elements with async == false. > > #3 is what currently doesn't "work" in webkit and in the spec. #2 is needed > to allay your concerns about implementing #3 regressing performance. #1 is > needed to make #2 possible. > > Is that unambiguous enough? Any questions? Concerns? Suggestions? Ballot > initiatives? ;) Decoupling the property from the attribute seems undesirable. Maybe we should try to address the use case directly rather than trying to hack around with the async attribute? Perhaps we should add a waitFor="foo bar" attribute to script elements that delays the execution of the script until all the scripts with the ids listed in the attribute execute (be they defer, async, normal, what-have-you). That would also have the advantage of being useable declaratively. Adam
Received on Monday, 18 October 2010 05:27:41 UTC