- From: Hallvord R. M. Steen <hallvord@opera.com>
- Date: Wed, 27 Oct 2010 13:49:05 +0900
- To: "Henri Sivonen" <hsivonen@iki.fi>
- Cc: "public html" <public-html@w3.org>
>> I actually like your document.executeScrips() proposal, it takes the >> use >> case LABjs demonstrates a demand for and ensures there is a built-in >> API >> that's easy enough sites can use it without requiring helper scripts. >> The >> counter-argument is feature creep.. > > Having a script execution mechanism that's not tied to HTMLScriptElement > nodes means that over time we'd potentially have to duplicate everything > that now assumes HTMLScriptElement nodes Agreed, it certainly adds complexity. >> Regarding the issues with the proposed use of async, would it help if >> we >> moved the feature detection away from the proposed >> "document.createElement('script').async==true", for example to >> HTMLScriptElement.defaultAsync ? >> var orderedScript=document.createElement('script'); >> orderedScript.src='foo.js'; >> if( HTMLScriptElement.defaultAsync ){ > Also, why bother with having .defaultAsync? This was mostly trying to find a solution to Adam's ugliness argument. (In that suggestion .defaultAsync was set directly on HTMLScriptElement rather than on the script instance, should perhaps in that case be all-upper case as it becomes a constant of sorts.) Personally I find looking for async==true on a newly created and not inserted (external) script more elegant from an author point of view. > If the definition of .async changed from what has been shipped in > Firefox 3.6, why would anyone want to use .defaultAsync? Wouldn't > .defaultAsync be there just "for completeness" as a matter of principle > of having IDL properties for all attributes specified in the language? > -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Received on Wednesday, 27 October 2010 04:49:54 UTC