Using XMLHttpRequest run locally for local data reading

[VK]

In continuation of http://groups.google.com/group/comp.lang.javascript/msg/787389d10afcaf77

Test (unzip and run AJAX/test/index.html):
http://sites.google.com/site/schoolsring/javascript
LocalDataReadingTest.zip


In each test:
1) attempt to read xml file in the same directory
2) attempt to read xml file in subdirectory
3) attempt to read xml file in top directory
4) attempt to read xml file in sibling directory

Each reading made twice: one time with without overriding MIME type,
next time with implied "text/xml" type.


1) IE
Internet Explorer 8.0 / Windows Vista SP2 - newest
Internet Explorer 6.0.2900 / Windows XP SP2 - legacy test

window.XMLHttpRequest in new IE does NOT allow local data reading at
all.

window.ActiveXObject(ProgID) doesn't support .overrideMimeType method

Without implied "text/xml" Content-type the results are:

OK attempt to read xml file in the same directory
OK attempt to read xml file in subdirectory
OK attempt to read xml file in top directory
OK attempt to read xml file in sibling directory

success request status = 0

.requestXML is empty, a manual serialization from responseText is
needed later.


2) Fx
Mozilla Firefox 3.6.3 / Windows Vista SP2 - newest
Mozilla Firefox 3.5.7 / Windows XP SP2 - legacy test

OK attempt to read xml file in the same directory
OK attempt to read xml file in subdirectory
_ attempt to read xml file in top directory (Error: Access to
restricted URI denied)
_ attempt to read xml file in sibling directory (Error: Access to
restricted URI denied)

success request status = 0

.requestXML is filled properly either with or without
using .overrideMimeType method


3) Sf
Apple Safari 4.0.5 / Windows Vista SP2

OK attempt to read xml file in the same directory
OK attempt to read xml file in subdirectory
OK attempt to read xml file in top directory
OK attempt to read xml file in sibling directory

success request status = 0

.requestXML is filled properly either with or without
using .overrideMimeType method


4) Ch
Google Chrome 4.1.249 / Windows Vista SP2

OK attempt to read xml file in the same directory
OK attempt to read xml file in subdirectory
OK attempt to read xml file in top directory
OK attempt to read xml file in sibling directory

success request status = 0

.requestXML is filled properly either with or without
using .overrideMimeType method


5) Op
Opera 10.51 / Windows Vista SP2

OK attempt to read xml file in the same directory
OK attempt to read xml file in subdirectory
OK attempt to read xml file in top directory
OK attempt to read xml file in sibling directory

success request status = 0

.requestXML is filled properly either with or without
using .overrideMimeType method


Conclusions:
1) IE sucks but usable
2) Fx is the most strict
3) overrideMimeType is useless: it is not needed where supported
and it is not supported where needed

4) The quality of XMLHttpRequest instantiation blocks in all
prominent libraries is *awful*... No, sorry: it is AWFUL. No... It is
a BLOODY AWFUL NIGHTMARE. The guys didn't read MSDN for years. If they
don't care about IE users whatsoever is fine, but they should
explicitly mark it then. I am posting the XHR init part from the test
file here - not as a sample of an outstanding coding, but at least to
show some descent approach with the crucial points commented:


function getAjaxObject(forLocalData) {

var isIE = /*@cc_on/*@if(@_jscript)true@else@*/false/*@end@*/;

var xhr = null;

if (typeof window == 'object') {

/* Common branch for modern browsers */
if (
(typeof window.XMLHttpRequest != 'undefined') &&
// window.XMLHttpRequest instances in IE do not
// have local file access even from local pages,
// unlike ActiveX instances: so if forLocalData
// flag set, we are trying to use the underlaying
// ActiveX constructor.
!(isIE && forLocalData)
) {
try {
return new window.XMLHttpRequest();
}
catch(e) {
return new Error(e.message);
}
}

/* ActiveX branch for old IE versions and for local data access
capable instances, see:
* http://blogs.msdn.com/xmlteam/archi...ht-version-of-msxml-in-internet-explorer.aspx
* http://groups.google.com/group/micr..._frm/thread/7772ac2ad016e2bf/5bd173be4950e107
* http://blogs.msdn.com/ie/archive/2006/01/23/516393.aspx
* for proper ProgID and proper ProgID trying sequence.
*/
else if (
(isIE) &&
(typeof window.ActiveXObject != 'undefined') // IE 5.x for MacOS
without ActiveX
) {
try {
return new window.ActiveXObject('Msxml2.XMLHTTP.6.0');
}
catch(e) {
try {
xhr = new window.ActiveXObject('Msxml2.XMLHTTP.3.0');
/* Msxml2.XMLHTTP.3.0 and older have XSL Patterns as the
* defailt XML language, not XPath, so fixing it:
*/
xhr.setProperty('SelectionLanguage', 'XPath');
return xhr;
}
catch(e) {
try {
xhr = new window.ActiveXObject('Msxml2.XMLHTTP');
/* Msxml2.XMLHTTP (IE6 / Win XP SP2 in default installation)
* have XSL Patterns as the defailt XML language, not XPath,
* but it doesn't support .setProperty switch.
* Setting the warning flag at the very least:
*/
arguments.callee.isXSLPatterns = true;
return xhr;
}
catch(e) {
/* Microsoft.XMLHTTP ProgID as the last ressort is not used
* as the security consideration should prevail over the
* maximum backward compatibility. Unlock for special cases only.
*/
//try {
// return new window.ActiveXObject('Microsoft.XMLHTTP');
//}
//catch(e) {
// return new Error(e.message);
//}
return new Error(e.message);
}
}
}
}

/* If nothing then nothing... */
else {
return new Error('ActiveX is missing or blocked');
}
}
else {
return new Error('window host object is missing');
}
}

 

[VK]

Conclusions:
 1) IE sucks but usable
 2) Fx is the most strict

....

5) async request checked for "200 OK" status only means either of two
things:
a) the coder has no clue about Ajax he/she dared to program
b) the coder deliberately decided to make his Ajax not usable for
local data
reading but failed to inform his/her users.

All good boys and girls (the one who reading c.l.j. always do like
this:

if ((myRequest.status == 200) || (myRequest.status == 0)) {
// success
}


6) XHR instantiation w/o explicit IE check and w/o possibility to flag
for ActiveX instead of XMLHttpRequest is a strong sign of i) a
clueless coding or ii) 5-b above

 

[Thomas 'PointedEars' Lahn]

[...] I am posting the XHR init part from the test file here - not as a
sample of an outstanding coding,

What else is new?

but at least to show some descent approach with the crucial points
commented:

In your fantasy world, perhaps.

function getAjaxObject(forLocalData) {

var isIE = /*@cc_on/*@if(@_jscript)true@else@*/false/*@end@*/;
OMG.

var xhr = null;

if (typeof window == 'object') {

/* Common branch for modern browsers */
if (
(typeof window.XMLHttpRequest != 'undefined') &&
[...]
!(isIE && forLocalData)
) {
[...]
}
[...]
else if (
(isIE) &&
(typeof window.ActiveXObject != 'undefined') // IE 5.x for MacOS
without ActiveX
) {

Apparently you are not paying attention.

try {
return new window.ActiveXObject('Msxml2.XMLHTTP.6.0');
}
catch(e) {
try {
xhr = new window.ActiveXObject('Msxml2.XMLHTTP.3.0');
[aso.]

Obviously you are not paying attention at all, or your puny mind is unable
to process or store the discussion results.


PointedEars

 

[VK]

Thomas, it is from a real production code, not usual c.l.j. child
games. It takes more efforts to comprehend, but the results are
fruitful. It is a JScript conditional compilation statement:
http://msdn.microsoft.com/en-us/library/7kx09ct1(VS.80).aspx
Any browser but IE will see false, IE will see true.

Why not the regular baby check
if (window.ActiveXObject) { ...
?

Because baby checks need baby efforts to spoof, like
if !!(window.ActiveXObject) {
window.ActiveXObject = new OurAjaxLoophole();
}

 var xhr = null;

 if (typeof window == 'object') {

/* Common branch for modern browsers */
  if (
    (typeof window.XMLHttpRequest != 'undefined') &&
[...]
    !(isIE && forLocalData)
   ) {
[...]
  }
[...]
  else if (
    (isIE) &&
    (typeof window.ActiveXObject != 'undefined') // IE 5.x for MacOS
without ActiveX
   ) {

Apparently you are not paying attention.

   try {
    return new window.ActiveXObject('Msxml2.XMLHTTP.6.0');
   }
   catch(e) {
    try {
     xhr = new window.ActiveXObject('Msxml2.XMLHTTP.3.0');
[aso.]

Obviously you are not paying attention at all, or your puny mind is unable
to process or store the discussion results.

No, it is just might be hard to realize how little one (you) know
about the real compatibility. The link to resources are provided right
and the code, read and learn. A separate hint as it is the most
popular urban legend about XHR on IE:
No, ActiveXObject('Msxml2.XMLHTTP') does NOT mean "take the latest/
current version". It means: "take the oldest one from all available".
For the rest keep study linked resources. Do not hesitate to ask for
explanations or for extra test cases for particular points.

 

[Thomas 'PointedEars' Lahn]

Thomas, it is from a real production code,

I pity your users already.

not usual c.l.j. child games.

It's your usual nonsense. JScript support has *nothing* to do with the
underlying DOM that provides the `XMLHttpRequest' and `ActiveXObject'
objects.

[...] It takes more efforts to comprehend,

One must be smoking what you are smoking to "comprehend" that.

but the results are fruitful.
Hardly.

It is a JScript conditional compilation statement:
http://msdn.microsoft.com/en-us/library/7kx09ct1(VS.80).aspx

I *know* what it is, stupid.

Any browser but IE will see false, [...]

Definitely no.

Why not the regular baby check
if (window.ActiveXObject) { ...
?

Nobody but you here recommends that, stupid.

Because baby checks need baby efforts to spoof, like
if !!(window.ActiveXObject) {
window.ActiveXObject = new OurAjaxLoophole();
}

That's not even syntactically valid.

var xhr = null;

if (typeof window == 'object') {

/* Common branch for modern browsers */
if (
(typeof window.XMLHttpRequest != 'undefined') &&
[...]
!(isIE && forLocalData)
) {
[...]
}
[...]
else if (
(isIE) &&
(typeof window.ActiveXObject != 'undefined') // IE 5.x for MacOS
without ActiveX
) {

Apparently you are not paying attention.

try {
return new window.ActiveXObject('Msxml2.XMLHTTP.6.0');
}
catch(e) {
try {
xhr = new window.ActiveXObject('Msxml2.XMLHTTP.3.0');
[aso.]

Obviously you are not paying attention at all, or your puny mind is
unable to process or store the discussion results.

No, it is just might be hard to realize how little one (you) know
about the real compatibility. [...]

Often Wrong, your code will _not_ work in MSHTML with local files to begin
with.


PointedEarws

 

[VK]

JScript support has *nothing* to do with the
underlying DOM that provides the `XMLHttpRequest' and `ActiveXObject'
objects.

Real production has *nothing* to do with theoretical masturbations.
ActiveXObject = IE. IE = ActiveXObject. For the rest - write poems on
c.l.j. Someone may read them.

I *know* what it is, stupid.

That's good for a starter.

Any browser but IE will see false, [...]

Definitely no.

Definitely yes, silly boy. You just claimed you knew the matter.

Often Wrong, your code will _not_ work in MSHTML with local files to begin
with.

OK, PointedEars, I am ready to have a harsh or not so harsh
*discussion* but I will not respond to a pure blind trolling. The test
results were received using this code, the code is posted as one zip
file to download. Get it and check it. If you want to call me a liar
who fabricates *results* (leaving out their interpretations for now) -
then you better do not do it.

 

[Thomas 'PointedEars' Lahn]

Real production has *nothing* to do with theoretical masturbations.
ActiveXObject = IE. IE = ActiveXObject. For the rest - write poems on
c.l.j. Someone may read them.

You're such an idiot:

<http://en.wikipedia.org/wiki/MSHTML#Trident-based_applications>


PointedEars

 

[VK]

You're such an idiot:

<http://en.wikipedia.org/wiki/MSHTML#Trident-based_applications>

You are so silly. What connection in your mind is between a rendering
engine .dll and COM / ActiveX? A hint: none, except the substrings
"MS" and "HTML" one can find both in .dll name and in some ProgIDs

Learn, learn, learn - that's the only salvation. At the spare time try
to use new ActiveXObject(whatever) in Winamp, it does use Trident as
well ;-)

 

[Thomas 'PointedEars' Lahn]

You're such an idiot:

<http://en.wikipedia.org/wiki/MSHTML#Trident-based_applications>

You are so silly. What connection in your mind is between a rendering
engine .dll and COM / ActiveX? A hint: none, [rubbish recycled]

The layout engine usually provides the host environment for DOM objects. It
is true that MSHTML does not need to mean ActiveX is also supported.
However, more important is that there is not a necessary connection between
_layout_ engine and the DOM binding it provides and the supported scripting
language. That is why your approach is junk.


PointedEars

 

[VK]

The layout engine usually provides the host environment for DOM objects.

Uhmm... It is a very simplistic way to put it, but OK.

It is true that MSHTML does not need to mean ActiveX is also supported.
However, more important is that there is not a necessary connection between
_layout_ engine and the DOM binding it provides and the supported scripting
language.

For IE of any version COM interfaces, accessible over
window.ActiveXObject, are not part of a rendering engine nor even part
of IE itself. They are programmed into JScript engine. And JScript
engine in IE of any version is one separate DLL library located at
%SystemRoot%System32/jscript.dll
It is made so because jscript.dll is not a part of IE, it is a system
dll needed for Windows Script Host functionality in its JScript part.
The other system dll %SystemRoot%System32/vbscript.dll provides WSH
VBScript part of functionality. So either one has IE installed or not,
these dll are there, unless the system is badly broken. But IE
installations may upgrade these dll to newer ones if instructed to do
so. So IE is just yet another user of jscript.dll. Moreover until IE7
it was possible to replace jscript.dll so making IE6 running with
JScript for IE5 or IE5 running with JScript for IE6. Funny, but
crashes quickly.

Any way, to make the long story shorter:
var isIE = /*@cc_on/*@if(@_jscript)true@else@*/false/*@end@*/;
effectively checks if the environment uses jscript.dll so running
Microsoft JScript of some (easy to check) version. If false, than it
is not Microsoft JScript, that is not jscript.dll and no way in the
world - atop of all other consequences - it may implement Microsoft
ActiveXObject. I am obviously talking about officially released
commercial software.

That is why your approach is junk.

This is why my approach is bulletproof and ActiveXObject feature
testing is junk.

P.S. As a side note I am a bit suspicious about IE-compatibility
experts claiming that they never had and/or not having any Microsoft
products and being happy with *nux or MacOS. This one not directly to
you, just an observation. Where do they get all their M$-related
wisdom? From their "mis-fortunate" M$'ed friends? As a sample of the
prevailing illiteracy on Msxml2.XMLHTTP topic this W3Schools "valuable
advise" at
http://www.w3schools.com/xpath/xpath_examples.asp
"To solve the [0] and [1] problem in IE5+, you can set the
SelectionLanguage to XPath."
Splendid! "This property or method is not supported" runtime error for
all IE users up to IE7, unless they manually updated their XMLHTTP
libraries.
About their XHR instantiation approach I have nothing to say at all:
http://www.w3schools.com/ajax/ajax_xmlhttprequest_create.asp
Whoever read comments in the code I posted will easily understand that
W3Schools is NOT a place to learn, at least about Ajax.
But hell with W3Schools - lousy were, lousy stay, lousy will remain.
The whole Web info like that on the topic, and respectively all libs
like that. "X said to Y that Z heard from... that..." And that's past
over 5 years after the "Ajax" explosion! http://www.adaptivepath.com/ideas/essays/archives/000385.php
What is wrong with the world?..

 

[VK]

All good boys and girls (the one who reading c.l.j. always do like
this:

 if ((myRequest.status == 200) || (myRequest.status == 0)) {
  // success
 }

Just got a bit down from my colleague for this advice. Just didn't
look into libraries for a long time, sorry.

Either for sync or async requests it has to accounted that for failed
attempt to read a local file (say file doesn't exists):

IE throws error on xhr.open(...) stage
Fx throws error on xhr.send('') stage
Sf returns .status -1100

Ch and Op return status 0 either for success or for error. That last
one implies that for local data reading .status is useless. One needs
to check responseText to see if anything in there. Actually it the
best way anyway. One needs responseText/responseXML data in the first
place, not .status data.
..status is useful if nothing found in responseText and you are trying
to figure out why.

And yes, open/send should be always placed into try-catch block.

 

[Eric Bednarz]

Test (unzip and run AJAX/test/index.html):
http://sites.google.com/site/schoolsring/javascript
LocalDataReadingTest.zip

I see two problems here. The good news is that one of them can be
solved. Use a newsreader.

[…] The guys didn't read MSDN for years.

I’m reminded of a dialog in A fish called Wanda, featuring apes, reading
and Nietzsche.

var isIE = /*@cc_on/*@if(@_jscript)true@else@*/false/*@end@*/;

This is a ridiculously verbose way of writing

var isIE = /*@cc_on true || @*/ false;

instead of

var isIE /*@cc_on = true @*/;

 

[VK]

This is a ridiculously verbose way of writing

  var isIE = /*@cc_on true || @*/ false;

instead of

  var isIE /*@cc_on = true @*/;

Do we have have a world keystroke shortage? Also it is a
conditional compilation, so I prefer to see conditionally compiled
blocks of *statements*, not pieces of them - despite IE will take it.
More important though that once @cc_on, it is on until @end or to the
end of source. Not important for a few liner, but making the engine
additionally check for pragma statements across 10-100Kb of text is
not efficient, so I @end cc right after it not needed anymore.
Question of taste and habits anyway. I just don't agree that full
syntax of anything can be "ridiculous". "Not necessary" is the max
IMHO.

 

[Eric Bednarz]

Do we have have a world keystroke shortage?

The problem is that confused syntax supports confused minds.

Also it is a
conditional compilation, so I prefer to see conditionally compiled
blocks of *statements*, not pieces of them - despite IE will take it.

Your gut feeling might be that an if statement assigned to a variable
makes more sense. That might explain it.

More important though that once @cc_on, it is on until @end or to the
end of source.

‘@end’ in CC pretty much does what programmers would intuitively expect
it to do in the context of a syntax that has blocks without braces.

I could say now that your problem is that you make things up while you
type, but that has been explained to you in this group… how often?


<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<title></title>
</head>
<body>
<script type='text/javascript'>
var isIE = /*@cc_on/*@if(@_jscript)true@else@*/false/*@end@*/;
isIE && alert(@_jscript_version);
</script>
</body>
</html>

 

[VK]

After more consultations posting the corrected stay-alone XHR
instantiation function with local data reading support. All comments
are inside the code. TinyURL service is used to accomodate long links
to Usenet posting.



function getAjaxObject(forLocalData) {

var f = arguments.callee;

var isIE = /*@cc_on true || @*/ false;;

var xhr = null;

if (typeof window == 'object') {

/* Common branch for modern browsers */
if (
(typeof window.XMLHttpRequest != 'undefined') &&
/* window.XMLHttpRequest instances in IE do not
* have local file access even from local pages,
* unlike ActiveX instances: so if forLocalData
* flag set, we are trying to use the underlaying
* ActiveX constructor.
*/
( !(isIE && forLocalData) )
) {
try {
return new window.XMLHttpRequest();
}
catch(e) {
return new Error(e.message);
}
}

/* ActiveX branch for old IE versions and
* for local data access capable instances. See:
* 1) http://tinyurl.com/MSDNBlog1
* 2) http://tinyurl.com/MSNewsGroup1
* 3) http://tinyurl.com/MSDNBlog2
* for proper ProgID and proper ProgID trying sequence.
*/
else if (
(isIE) &&
/* if IE 5.x for MacOS without ActiveX: */
(typeof window.ActiveXObject != 'undefined')
) {
try {
xhr = new window.ActiveXObject('Msxml2.XMLHTTP.6.0');
f.isActiveX = true;
f.ActiveXVersion = 6;
return xhr;
}
catch(e) {
try {
xhr = new window.ActiveXObject('Msxml2.XMLHTTP.3.0');
/* Contrary to numerous MS claims like here:
* http://tinyurl.com/SelectionLanguage
* Msxml2.XMLHTTP.3.0 (IE6 / Win XP SP2 by default)
* does not have XSL Patterns as the default language
* neither it supports setProperty method so trying
* to apply setProperty("SelectionLanguage", "XPath")
* leads to "not supported" runtime error on IE6.
* In the reality the last COM with XSL Patterns were
* in XMLHTTP.2.x versions. Looks pretty much as a MS
* internal urban legend.
*/
f.isActiveX = true;
f.ActiveXVersion = 3;
return xhr;
}
catch(e) {
/* As per MS Security Bulletin http://tinyurl.com/MS06-061
* Msxml2.XMLHTTP.2.x and older like Microsoft.XMLHTTP can
* be blocked and overall the security considerations
* should prevail over the maximum backward compatibility.
* Add these branches only if you really need to support
* IE 5.x in a non-commercial home use solution.
*/
return new Error(e.message);
}
}
}
/* If nothing then nothing... */
else {
return new Error('ActiveX is missing or blocked');
}
}
else {
return new Error('window host object is missing');
}
}

 

[VK]

I could say now that your problem is that you make things up while you
type

No, I am just following what is written on the producer page. The
current CC docs
http://msdn.microsoft.com/en-us/library/7kx09ct1(v=VS.80).aspx
http://msdn.microsoft.com/en-us/library/ct27x3xa(v=VS.80).aspx
is a complete rewrite with JScript 8.0 as a target at the top of the
page. At the time I was reading it a few years ago the target was
JScript 5.6 and
1) @cc_on - @end was given as "pragma parser on/off" paired statements
2) @elif was not documented nor mentioned anywhere at all. I saw it a
code snippet in MSDN this is how I "discovered" it.

In relation to @end I tested it on IE6 / Win XP and your statement
about it being just closing part of @if-@elif-@else-@end block is
right. And @cc_on once used keeps pragma parser on till the end of
source. So either it was a change from IE5 to IE6 or - most probably -
bad documentation from the very beginning.

 

[Thomas 'PointedEars' Lahn]

No, I am just following what is written on the producer page. The
current CC docs
http://msdn.microsoft.com/en-us/library/7kx09ct1(v=VS.80).aspx
http://msdn.microsoft.com/en-us/library/ct27x3xa(v=VS.80).aspx
is a complete rewrite with JScript 8.0 as a target at the top of the
page. At the time I was reading it a few years ago the target was
JScript 5.6 and
1) @cc_on - @end was given as "pragma parser on/off" paired statements
2) @elif was not documented nor mentioned anywhere at all.

You are even a lousier liar than you are a programmer:

<http://msdn.microsoft.com/en-us/library/8ka90k2e(VS.71).aspx>
<http://msdn.microsoft.com/en-us/library/8ka90k2e(VS.80).aspx>
<http://msdn.microsoft.com/en-us/library/8ka90k2e(VS.85).aspx>

<http://msdn.microsoft.com/en-us/library/58dz2w55(VS.71).aspx>
<http://msdn.microsoft.com/en-us/library/58dz2w55(VS.80).aspx>
<http://msdn.microsoft.com/en-us/library/58dz2w55(VS.85).aspx>


PointedEars

 

[VK]

You are even a lousier liar than you are a programmer:

Hardly, as long a you are here.

<http://msdn.microsoft.com/en-us/library/8ka90k2e(VS.71).aspx>
<http://msdn.microsoft.com/en-us/library/8ka90k2e(VS.80).aspx>
<http://msdn.microsoft.com/en-us/library/8ka90k2e(VS.85).aspx>

<http://msdn.microsoft.com/en-us/library/58dz2w55(VS.71).aspx>
<http://msdn.microsoft.com/en-us/library/58dz2w55(VS.80).aspx>
<http://msdn.microsoft.com/en-us/library/58dz2w55(VS.85).aspx>

So? In the way MSDN organizes its dynamic URLs the Wayback Machine is
useless. Again: in the way it is written now is day and night by its
completeness and clearness in comparison with 2004-2005. That time it
was more a set of obscure hints one needed to get together and to
decrypt.

Any way, the check is updated for a shorter form proposed by Eric
Bednarz. Any *constructive* comments on the new getAjaxObject code?

 

[Thomas 'PointedEars' Lahn]

No, I am just following what is written on the producer page. The
current CC docs
http://msdn.microsoft.com/en-us/library/7kx09ct1(v=VS.80).aspx
http://msdn.microsoft.com/en-us/library/ct27x3xa(v=VS.80).aspx
is a complete rewrite with JScript 8.0 as a target at the top of the
page. At the time I was reading it a few years ago the target was
JScript 5.6 and
1) @cc_on - @end was given as "pragma parser on/off" paired statements
2) @elif was not documented nor mentioned anywhere at all.

You are even a lousier liar than you are a programmer: [...]
<http://msdn.microsoft.com/en-us/library/8ka90k2e(VS.71).aspx>
<http://msdn.microsoft.com/en-us/library/8ka90k2e(VS.80).aspx>
<http://msdn.microsoft.com/en-us/library/8ka90k2e(VS.85).aspx>

<http://msdn.microsoft.com/en-us/library/58dz2w55(VS.71).aspx>
<http://msdn.microsoft.com/en-us/library/58dz2w55(VS.80).aspx>
<http://msdn.microsoft.com/en-us/library/58dz2w55(VS.85).aspx>

So? In the way MSDN organizes its dynamic URLs the Wayback Machine is
useless.

The URLs may have changed, but the content has been the same *for years*.

Again: in the way it is written now is day and night by its completeness
and clearness in comparison with 2004-2005. That time it was more a set of
obscure hints one needed to get together and to decrypt.

No, it evidentially (sic!) was/is not. Your problem is that you are either
incapable to understand what you read, or to remember what you have read; so
you are making things up while you are typing, as Eric correctly observed.
Or you are an awful liar. Take your pick.

And learn to quote, if you can learn nothing else.


PointedEars

 

[VK]

Uhmm... I guess I forgot to mention how to eventually get XML from
responseText for IE. IE's serialization ways are numerous, version-
dependent and boring. See for instance:
http://groups.google.com/group/microsoft.public.xml/browse_frm/thread/822f8a6df3214c1d

Because for other browsers this problem doesn't arise, we can be IE
specific and use quick, dirty and amusingly effective way using IE-
specific XML Data Islands tools and IE's <XML> tag.

So assuming we've got responseText filled, responseXML empty and we
know that it should be a well-formed XML file, we simply do that:

var tmp = document.createElement('DIV');
tmp.innerHTML = '<XML>' + xhr.responseText + '</XML>';
return tmp.firstChild.XMLDocument.documentElement;

Respectively for a HTML fragment we can do:

var tmp = document.createElement('DIV');
tmp.innerHTML = xhr.responseText;
return tmp.firstChild;

Enjoy!