Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #20103

Re: Parallel Download Abstraction

Show all headers | View raw

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:
>> >>
>> >> <https://developers.google.com/speed/articles/include-scripts->> >> 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.
> 
> <https://thenewobjective.com/tests/parallel-downloads/>
> 
> 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]
<https://thenewobjective.com/tests/parallel-downloads/inline-script.html>
 
>> 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 <http://en.wikipedia.org/wiki/Castling>
(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 –

<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Same_origin_policy_for_JavaScript>

– and elsewhere.  XSS is a different issue:

<https://developer.mozilla.org/en-US/docs/Security/CSP/Introducing_Content_Security_Policy>

>> 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: <https://blogs.msdn.com/b/kristoffer/archive/2006/12/22/loading-> 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:
>>
>> <http://www.w3.org/TR/1999/REC-html401-19991224/interact/scripts.html#...>
>> <http://www.w3.org/TR/1999/REC-html401-19991224/present/styles.html#ed...>
> 
> I'm referring to the following:
> <http://www.w3.org/TR/html401/present/styles.html#h-14.2.1>
> 
> <quote>
> 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".
> </quote>

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

| <!ELEMENT STYLE - - %StyleSheet        -- style info -->
| <!ATTLIST STYLE
|   %i18n;                               -- lang, dir, for use with title --
|   type        %ContentType;  #REQUIRED -- content type of style language
                               ^^^^^^^^^
| --

If there were a default value of "text/css" for the “type” attribute of the 
STYLE element, the attribute declaration would look as follows:

<!ATTLIST STYLE
  -- […] --
  type        %ContentType; "text/css" -- content type of style language --
  -- […] --

See for example:

,-<http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#edef-FORM>
| 
| <!ATTLIST FORM
|   %attrs;                              -- %coreattrs, %i18n, %events --
|   action      %URI;          #REQUIRED -- server-side form handler --
|   method      (GET|POST)     GET       -- HTTP method used to submit the
| form--
|   enctype     %ContentType;  "application/x-www-form-urlencoded"
| […]

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Parallel Download Abstraction "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-05-29 17:09 -0700
  Re: Parallel Download Abstraction Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-30 03:01 +0200
    Re: Parallel Download Abstraction "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-05-29 19:17 -0700
      Re: Parallel Download Abstraction Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-30 05:13 +0200
        Re: Parallel Download Abstraction "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-05-30 17:56 -0700
          Re: Parallel Download Abstraction Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-31 14:59 +0200
            Re: Parallel Download Abstraction "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-06-01 03:18 -0700
              Re: Parallel Download Abstraction Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-06-01 15:10 +0200
                Re: Parallel Download Abstraction "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-06-01 18:21 -0700
                Re: Parallel Download Abstraction Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-06-03 14:50 +0200
                Re: Parallel Download Abstraction Stefan Weiss <krewecherl@gmail.com> - 2013-06-04 02:20 +0200
                Re: Parallel Download Abstraction Scott Sauyet <scott.sauyet@gmail.com> - 2013-06-03 18:04 -0700
                Re: Parallel Download Abstraction "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-06-03 20:01 -0700
              Re: Parallel Download Abstraction Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-06-01 15:15 +0200
                Re: Parallel Download Abstraction "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-06-01 18:05 -0700

csiph-web