Path: csiph.com!usenet.pasdenom.info!dedibox.gegeweb.org!gegeweb.eu!nntpfeed.proxad.net!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <1813184.oRGPi3HU2c@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Mail-Copies-To: usenet@PointedEars.de Organization: PointedEars Software (PES) Date: Fri, 31 May 2013 14:59:07 +0200 User-Agent: KNode/4.10.2 Content-Transfer-Encoding: 8Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. <3159554.1y7rF9eUTa@PointedEars.de> <1672892.tfqf7eurea@PointedEars.de> <4cf2860f-135f-4895-8296-ed560062633c@k4g2000yqb.googlegroups.com> MIME-Version: 1.0 Lines: 105 NNTP-Posting-Date: 31 May 2013 14:59:22 CEST NNTP-Posting-Host: 42d045ce.newsspool2.arcor-online.net X-Trace: DXC=\e[X4IAfdIYE47KDAk81NWA9EHlD;3YcR4Fo<]lROoRQ8kF Thomas 'PointedEars' Lahn wrote: >> I said “also” because it is unlikely that either of the two approaches >> will result in “parallel download”. Scripts, when included this way, are >> always processed sequentially, and AFAIK are also downloaded >> sequentially: >> >> > > Actually, the scripts are downloaded in parallel but executed in the > order they're written to the page. This works in legacy IE as well, How do you know that? Both the text and the video there suggest that script resources are always downloaded sequentially, to the point that they block parsing of subsequent markup. > though from testing it looks like it is irrelevant in modern browsers. Please post the public URI of your pertinent testcase(s), list the UAs and describe the methods that produced your results. >> Usually it is a bad idea to use document.write() to include content, >> particularly script content, nowadays: >> >> > > I agree if I was only targeting modern browsers which can actually > perform the mentioned, static, predictive downloading. The MSDN Library library suggests that Element::appendChild() has been supported since MSHTML 5.x (1999/2000); caniuse.com and the local DOM Support Matrix provide no pertinent information yet. Previously there were .insertAdjacentHTML() and .innerHTML, although I am not sure if the earlier UAs would load scripts included this way (and I cannot test it). >> A possibility for parallel download is asynchronous XHR using two >> different XHR instances, and inserting “script” elements with the >> resource's content each upon completion, as I do synchronously in >> jsx.importFrom(): >> >> [URI] >> >> (Changing that to asynchronous loading is accomplished by simply passing >> “true” instead of “false” for the third argument. I shall work on that; >> to date it did not occur to me that it could be useful to load scripts >> asynchronously.) > > Cross-Domain issues not-withstanding of course. Good point. If such an issue would occur, should the method automatically fall back to “script” element insertion to which the SOP does not apply by default? >> I did not comment on the missing escaping of because from your >> being >> parsed as the end-tag of the “script” element: >> >> [URI] >> >> That said, for backwards-compatibility it is certainly wise to escape >> “ > Your assumption gave me too much credit in this case. It was a typo; I > was also unaware that this escaping was no longer necessary. Escaping “> Likewise for using “type="text/javascript"” on “script” elements and >> “type="text/css"” on “style” elements. > > HTML 5 states that this is optional for