W3C home > Mailing lists > Public > public-html@w3.org > November 2010

Re: Executing script-inserted external scripts in insertion order

From: Getify <getify@gmail.com>
Date: Thu, 4 Nov 2010 12:27:38 -0500
Message-ID: <CA2B864ECD5A44DF88CD7E79FFEB353F@spartacus>
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:


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 


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

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:26 UTC