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

Groups > comp.lang.javascript > #20063

Re: Parallel Download Abstraction

Show key headers only | View raw

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.
 
>> Usually it is a bad idea to use document.write() to include content,
>> particularly script content, nowadays:
>>
>> <https://developers.google.com/speed/docs/best-practices/rtt?hl=en#Avo...>
> 
> 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 </script> because from your
>> <script> tag I assumed that you would use HTML5, and I assumed that
>> because it is not SGML-based, escaping of “</” was no longer necessary
>> there. However, indeed it is still necessary to avoid </script> being
>> parsed as the end-tag of the “script” element:
>>
>> [URI]<http://www.w3.org/TR/2012/CR-html5-20121217/scripting-1.html#restrict...>
>>
>> That said, for backwards-compatibility it is certainly wise to escape
>> “</” *always* within a “script” element.
> 
> 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 “</” *is* still necessary in HTML5, but only for pseudo-end-tags of 
pseudo-“script” elements within proper “script” elements, and probably (I 
have not checked the grammar) for pseudo-end-tags of pseudo-“style” elements 
in proper “style” elements.  Unless I have not considered another element 
type.
 
>> Likewise for using “type="text/javascript"” on “script” elements and
>> “type="text/css"” on “style” elements.
> 
> HTML 5 states that this is optional for <script> tags, and while HTML
> 4 requires it, the de-facto default has been "text/javascript".

Possible, unless you used a different scripting language (like VBScript) 
before said SCRIPT element.  I am also not sure about MSHTMLs language 
labels in “href” and event-handler attribute values.

> While I've never come across the issue, nor expect to, I can see the
> argument that it is possible for some server misconfiguration to set
> an innapropriate "Content-Script-Type" header.
> 
> 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#edef-SCRIPT>
<http://www.w3.org/TR/1999/REC-html401-19991224/present/styles.html#edef-STYLE>

The pertinent META elements and corresponding HTTP header fields are 
supposed to apply only to event-handler attribute values and the “style” 
*attribute* (ibid.; see below and above that, respectively).  I am not aware 
of a UA that observes them for SCRIPT and STYLE elements, respectively.

-- 
PointedEars

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