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

On Sep 27, 2007, at 1:20 AM, Mike Wilson wrote:

> 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.

That was the original goal, but it turned out to be too hard to make a  
useful spec based on this - see below.
> 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 personally have no objection to changing the spec to be closer to IE  
behavior, if Microsoft has specific changes to request. This is  
justifiable both for compatibility reasons and possibly as a courtesy.  
Their request so far is instead to make the spec requirements less  
specific, so that implementations could have large differences in  
behavior but still be conforming. That is what I am against.

>  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).

Vendors other than Microsoft have already been making changes to their  
XHR implementations to align with the spec. It's true that IE adoption  
rates are slower, but this cuts both ways. It's not clear if IE7 will  
pass IE6 in usage share by the time IE8 comes out.
> 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.

This would have to be content that cares about IE7 but not other  
browsers or IE6. For now at least, it appears that IE6 is still the  
most popular browser <http://marketshare.hitslink.com/report.aspx?qprid=6 
 >.

Regards,
Maciej