W3C home > Mailing lists > Public > public-webapi@w3.org > September 2007

Re: FW: Feedback from the IE Team: Web API XHR Draft

From: Jon Ferraiolo <jferrai@us.ibm.com>
Date: Wed, 26 Sep 2007 08:10:00 -0700
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Cc: "public-webapi@w3.org" <public-webapi@w3.org>, Sunava Dutta <sunavad@windows.microsoft.com>
Message-ID: <OF68B9ED49.9602B9B3-ON88257362.0051FC58-88257362.00535068@us.ibm.com>

I haven't been following the technical discussion in enough detail to have
a definitive opinion about whether there is a need to address Microsoft's
concerns about ensuring backwards compatibility with existing web content,
but I have a knee jerk positive reaction whenever I hear a browser vendor
express concerns about "not breaking the Web", meaning that they want to
make sure that future versions of browsers do not cause existing content to
quit working.

I don't know if a new class (XHR2) or a version property are truly required
in order to address backwards compatibility with existing content (i.e.,
don't break the Web). I'll leave that to the experts on the WG. But I will
point out that nearly all Web developers today that use XHR use a wrapper
JavaScript function. Here is a simple one that reflects what you'll find in
an Ajax tutorial:

function getHTTPObject() {
  var xmlhttp;
  @if (@_jscript_version >= 5)
    try {
      xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (e) {
      try {
        xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
      } catch (E) {
        xmlhttp = false;
  xmlhttp = false;
  @end @*/
  if (!xmlhttp && typeof XMLHttpRequest != 'undefined') {
    try {
      xmlhttp = new XMLHttpRequest();
    } catch (e) {
      xmlhttp = false;
      if (!xmlhttp && window.createRequest) {
            try {
                  xmlhttp = window.createRequest();
            } catch (e) {
  return xmlhttp;

I looked at the Dojo and Yahoo libraries. Their XHR wrapper logic is
similar but is implemented using a table-driven approach. Dojo includes the
following array "d._XMLHTTP_PROGIDS = ['Msxml2.XMLHTTP',
'Microsoft.XMLHTTP', 'Msxml2.XMLHTTP.4.0'];" and then loops through it
before returning an XHR object to the application.

Therefore, if the WG concludes that MS's backwards compatibility concerns
are valid, and therefore it becomes necessary to create either a new class
or attach version data to the XHR class, then do so in a manner that allows
JS wrapper functions to include appropriate conditional logic.


             Lachlan Hunt                                                  
             hy.id.au>                                                  To 
             Sent by:                  Jon Ferraiolo/Menlo Park/IBM@IBMUS  
             public-webapi-req                                          cc 
             uest@w3.org               Sunava Dutta                        
             09/26/2007 05:48          <public-webapi@w3.org>              
             AM                                                    Subject 
                                       Re: FW: Feedback from the IE Team:  
                                       Web API XHR Draft                   

Jon Ferraiolo wrote:
> The idea that there is a new JavaScript class (XHR2?) or a different
> version of the XHR object seems reasonable to me.

Introducing a brand new version of XHR doesn't solve the existing
interoperability problems the current version that people actually use.
  I am opposed to introducing another new object for this problem.  IE
already has ActiveXObject("Microsoft.XMLHTTP") that it can use for
legacy compat while making XMLHttpRequest() conform to this spec.

Lachlan Hunt

(image/gif attachment: graycol.gif)

(image/gif attachment: pic17827.gif)

(image/gif attachment: ecblank.gif)

Received on Wednesday, 26 September 2007 15:11:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:24 UTC