- From: Getify <getify@gmail.com>
- Date: Thu, 4 Nov 2010 12:27:38 -0500
- To: "public html" <public-html@w3.org>
?Thank you to those of you who have helped this discussion along thus far. I'd like to make one final call for those who participated in this thread to solidify the discussion points (for and against) on the main proposal, over on the wiki page I set up: http://wiki.whatwg.org/wiki/Dynamic_Script_Execution_Order As both FF and Safari are potentially nearing upcoming releases, and at the moment (AFAIK) both are broken on this use case, I think it's really important we start narrowing down to what a viable solution/compromise can be. If Mozilla and Webkit can take that discussion as guidance on how to address the issue in their upcoming release, that will lower some of the pressure on forcing us to get a fully standardized approach in such a short period of time. Moreover, IE9 is also probably nearing the end of its release cycle, so we're at a crucial time where we have a chance to fix this problem relatively quickly, if we can agree on what a good (or acceptable) fix can be. Obviously, if at all possible, I want to avoid having to go back to sites like Zappos and Twitter to suggest they suspend use of LABjs (or rather to cripple the parallel performance features) for an indefinite period of time while this issue plays out, having to wait for the next release cycle of the browsers in question. Please use the "discussion"/"talk" feature of the Wiki to surface any significant concerns that are not yet properly addressed in the Wiki, or if more appropriate, just update the main page itself. Also, those of you on this list who work for Mozilla, Webkit/Chrome, Opera, and IE... please make sure that the relevant decision makers on your respective teams have seen the discussion and proposal, and ask them to surface any vendor concerns they have ASAP. It'd be great if we could get a "roll call" of sorts from each of the browsers on if they think there's any short term viability or likelihood of them implementing the current main proposal. --Kyle -------------------------------------------------- From: "Adam Barth" <w3c@adambarth.com> Sent: Tuesday, November 02, 2010 1:43 PM To: "Henri Sivonen" <hsivonen@iki.fi> Cc: "Tony Gentilcore" <tonyg@google.com>; "Getify" <getify@gmail.com>; "public html" <public-html@w3.org> Subject: Re: Executing script-inserted external scripts in insertion order > On Tue, Nov 2, 2010 at 6:48 AM, Henri Sivonen <hsivonen@iki.fi> wrote: >> On Oct 30, 2010, at 02:38, Tony Gentilcore wrote: >> >>> Nice writeup! The .async=false proposal you outline in the wiki looks >>> great to me. I'm happy to put together a WebKit patch if we settle on it >>> and there's a bug for Hixie to update the spec. >> >> FWIW, the Gecko patch that up for review has the following behavior for >> .async in spec-ese: >> >> When a script element node is created, if it is being flagged as >> parser-inserted, set its force-async flag to false. Otherwise, set its >> force-async flag to true. (Note that createContextualFragment, innerHTML >> and XSLTProcessor::transformToFragment-created scripts are not flagged as >> parser-inserted.) This flag setting happens before any attributes are set >> on the node. >> >> When a previously-created script element node loses its >> parser-insertedness, if the element doesn't have the async content >> attribute, set the force-async flag to true and false otherwise. >> >> When a script element node obtains the async content attribute (via >> setAttribute, setAttributeNode, setAttributeNS, by the fragment parsing >> algorithm or the XSLTProcessor adding the attribute, etc.), set the >> force-async flag to false. (Note that calling removeAttribute("async") >> doesn't modify the force-async flag.) >> >> The async IDL attribute must behave as follows: >> * Upon setting, set the force-async flag to false and then reflect the >> async content attribute. >> * Upon getting, if the force-async flag is true, return true. Otherwise, >> reflect the async content attribute. > > ^^^^^^^^^^^^^^^ This is the part that makes me sad. > >> (And the "run" algorithm for scripts is extended with an additional case >> for scripts that are external, aren't flagged as parser-inserted and that >> have the async DOM property reporting false.) >> >> -- >> Henri Sivonen >> hsivonen@iki.fi >> http://hsivonen.iki.fi/ >> >> >> >> >
Received on Thursday, 4 November 2010 17:28:16 UTC