RE: Feedback from the IE Team: Web API XHR Draft

From: Maciej Stachowiak
To: Sunava Dutta
Cc: public-webapi@w3.org
Subject: Re: Feedback from the IE Team: Web API XHR Draft

Hi Sunava, 


Thanks for sending this feedback.


Here are my high-level comments:


1) I am strongly opposed to greatly weakening the implementation conformance
requirements. Changing the spec requirements so that existing
implementations, even if they vary significantly in behavior, are already
conforming. The reason we have specifications is to enable better
interoperability. If the specification simply rubber stamps all existing
implementations, which differ enough to cause interoperability problems,
then we will do nothing to achieve this goal.  

Agreed. 

There is a possible alternate goal of documenting for authors what current
implementations do and giving them enough information to target the
interoperable subset.  

I too haven't followed the XHR discussion in detail for a while, but I
remember that the goal previously was to have the XHR spec reflect current
implementation(s?) of XHR, and once that was finalized the next version of
the spec would introduce new requirements and improvements. 

But it turned out in the course of developing the spec that there were
enough individually small differences to make such an excercise fruitless. 

Considering that IE "invented" XHR (apart from the object naming), couldn't
the first version of the spec just describe the existing IE behaviour in
detail? That would match the previous wg intention and certainly make things
easy for the IE team and their backwards compatibility. That would mean the
first step in the following plan:
1) Describe original XHR implementation(s) in detail.
2) Iron out kinks and upgrade to new DOM/BOM types without adding
functionality.
3) Add functionality (currently some mentioned as "future" or "Not in this
Specification").
 
I guess you have already been through this discussion, dropped it, and
instead decided to go for step (2) of the plan above. Though, my
interpretation of the IE team's thoughts is that it is a lot of work for
them to comply with step (2) and still they have not gained any new
functionality, only created backwards compatibility problems. The history of
web browsers have been about getting new things done, so I think there could
be other vendors also not rushing to fulfill step (2) but instead waiting
for (3).
 
So, my point here is: while I think (2) is a great way to formalize current
XHR in a future-proof way, I don't expect quick adoption. If this is the
goal I think it will have a high risk of failing.
If the goal for (2) is to be just an intermediate step (spec-wise) that
vendors will not implement on itself, then fine, the step (3)
implementations will be far enough into the future so vendors (including
MS/IE) will have more time to plan and comply with the new stuff in step
(2).

We don't have window.document2 to access a DOM2-capable DOM.  

This is a very good point.

B) Microsoft already has an IE-specific legacy interface that could be used
for a 100% backwards-compatible version of XHR: new
ActiveXObject("Microsoft.XMLHTTP"). Support for the new XMLHttpRequest()
syntax is new to IE7, therefore it is likely that old or even new
IE-specific content uses the ActiveXObject syntax. Content that exclusively
uses the XMLHttpRequest syntax is  more likely to depend on Firefox
behavior. Therefore it seems unlikely the compatibility risk with XHR is
that severe, indeed, it might be outweighed by the sites that would newly
work.

Agreed, but it contradicts my guess-work above about adoption time. By the
time IE has implemented the referenced DOM/BOM types there may be a large
installed base using "old-school" IE7 XMLHttpRequest. 
 
Best regards
Mike Wilson