Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.mixmin.net!newsfeed.fsmpi.rwth-aachen.de!uucp.gnuu.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <3050803.YGT5ROo5qm@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Sat, 01 Jun 2013 15:10:17 +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> <1813184.oRGPi3HU2c@PointedEars.de> MIME-Version: 1.0 Lines: 184 NNTP-Posting-Date: 01 Jun 2013 15:10:22 CEST NNTP-Posting-Host: 465635cc.newsspool1.arcor-online.net X-Trace: DXC=FWUR92ZlV@R<<0iRN7DLEQic==]BZ:af^4Fo<]lROoRQnkgeX?EC@@P:HSIQ^WeSTRDZm8W4\YJN\b@mF9jNikdU7a5\<`>]gf^:81I4o?NRKX X-Complaints-To: usenet-abuse@arcor.de Xref: csiph.com comp.lang.javascript:20103 Michael Haufe (TNO) wrote: > Thomas 'PointedEars' Lahn wrote: >> Michael Haufe (TNO) wrote: >> > 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: >> >> >> >> > >> properly> >> >> >> > 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. > > > > results thus far: > > Browser normal document.write > […] > Ch 27 parallel parallel > > […] Thank you. Using your testcases and the Chrome Developer Tools' “Network” tab, in 10 out of 10 cases I can confirm parallel (“P”) uncached download for the document.write() approach in "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.93 Safari/537.36" I cannot confirm your observations for the “normal” way (static script elements [1]) there. In most cases scripts are downloaded uncached sequentially (“S”) instead, as demonstrated in the video by Tony Gentilcore (Co-Creator of the Google PageSpeed Tools) in what looks like IE 9 (referred above). Uncached run # | 1 2 3 4 5 6 7 8 9 10 -----------------+------------------------------ normal/inline | P S S S P S S S S S document.write() | P P P P P P P P P P [1] >> 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). > > If memory serves correct, I think Firefox restricted this behavior > around version 3 for XSS security (This may only be for html from a 3rd > party though). It couldn't hurt to test. I have just tested it in "Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0 Iceweasel/18.0.1" in the Firebug 1.11.4 console on (which I happened to have visited last there) with /* Kids, don't try this at home! */ var script = document.createElement("script"); script.src = "http://PointedEars.de/scripts/object.js"; document.body.appendChild(script); It works (jsx.object is available then). If you think about it, you *had* to be mistaken about a general restriction for cross-origin scripts: if you had been correct, for example the Google Maps API would have stopped working except on the Google Maps web site from Firefox 3.0 on. And a lot of web trackers, including Google Analytics, would suddenly have failed. You will find inserting “script” elements documented as a way to work around the SOP in MDN – – and elsewhere. XSS is a different issue: >> Good point. If such [an cross-origin issue with XHR] would occur, should >> the method automatically fall back to “script” element insertion >> to which the SOP does not apply by default? > > The problem here though is that I am under the impression that legacy > IE executes external scripts (outside of document.write) in the order > they are loaded and not when attached to the document like Fx and others. > Ref: javascript-files-in-parallel.aspx?Redirected=true> Interesting. I shall test that assertion then. > Of course you could argue that would be the script authors' fault for > relying on ordered dependencies and assuming properties of the utilizing > environment. > > I would suggest making it explicit which approach is used as the > semantics differ. ACK. >> > For styles, the default in both standards is "text/css" >> >> The “type” attribute is #REQUIRED on the SCRIPT *and* STYLE element in >> HTML 4. There is no default value: >> >> >> > > I'm referring to the following: > > > > User agents should determine the default style sheet language for a > document according to the following steps (highest to lowest > priority): > > 1. If any META declarations specify the "Content-Style-Type", the last > one in the character stream determines the default style sheet > language. > 2. Otherwise, if any HTTP headers specify the "Content-Style-Type", > the last one in the character stream determines the default style > sheet language. > 3. Otherwise, the default style sheet language is "text/css". > And AISB, this is followed by: | Documents that include elements that set the style attribute but which ^^^^^^^^^ | don't define a default style sheet language are incorrect. Authoring tools | should generate default style sheet language information (typically a META | declaration) so that user agents do not have to rely on a default of | "text/css". and later | | | |