I honestly don't think that was the point at all. Yes, XHR allowed for AJAX to follow, and was rather revolutionary. That said, the original implementation was very tied not just to MSIE, but to ActiveX and, by extension, to the Windows platform. It was not even in principle possible for Mozilla, Opera and others to implement XHR as originally implemented by MS, since to do so would require implementing ActiveX support. Rather, cross-browser support for XHR required developing a second, incompatible API. Similar concerns hold back implementing support for MSIE's "filter" CSS properties and several other such experiments.
> It was not even in principle possible for Mozilla, Opera and others to implement XHR as originally implemented by MS, since to do so would require implementing ActiveX support.
Incorrect. The code to create an XHR object in IE looked something like this:
var xhr = new ActiveXObject("Msxml2.XMLHTTP.6.0");
Any browser could absolutely have supported creating XHR objects in this manner without being forced to support ActiveX.
Right up until MS changed their implementation, say to version 7. MSIE's implementation of XHR exposed internal details of the ActiveX-based implementation which were subject to change-- it was never meant to be an external API, but rather, to enable features in Outlook Web Access. Thus, any third-party implementation would have to involve making a list of special magic strings to recognize in the ActiveXObject() call, then delegate to code that attempts to replicate internal implementation details of the given ActiveX object.
Microsoft did stuff the Microsoft way. There's no question that there are horrible bugs people have to deal with due to crazy implementations.
Inhuman monsters is way way over the top. The IE team can take credit for plenty of bugs, but they can also take credit for some pretty neat things as well.
Comments
I honestly don't think that was the point at all. Yes, XHR allowed for AJAX to follow, and was rather revolutionary. That said, the original implementation was very tied not just to MSIE, but to ActiveX and, by extension, to the Windows platform. It was not even in principle possible for Mozilla, Opera and others to implement XHR as originally implemented by MS, since to do so would require implementing ActiveX support. Rather, cross-browser support for XHR required developing a second, incompatible API. Similar concerns hold back implementing support for MSIE's "filter" CSS properties and several other such experiments.
> It was not even in principle possible for Mozilla, Opera and others to implement XHR as originally implemented by MS, since to do so would require implementing ActiveX support.
Incorrect. The code to create an XHR object in IE looked something like this:
var xhr = new ActiveXObject("Msxml2.XMLHTTP.6.0");
Any browser could absolutely have supported creating XHR objects in this manner without being forced to support ActiveX.
Right up until MS changed their implementation, say to version 7. MSIE's implementation of XHR exposed internal details of the ActiveX-based implementation which were subject to change-- it was never meant to be an external API, but rather, to enable features in Outlook Web Access. Thus, any third-party implementation would have to involve making a list of special magic strings to recognize in the ActiveXObject() call, then delegate to code that attempts to replicate internal implementation details of the given ActiveX object.
If non-ActiveX browsers had started deliberately breaking feature detection, the browser wars would have been even worse.
Microsoft did stuff the Microsoft way. There's no question that there are horrible bugs people have to deal with due to crazy implementations.
Inhuman monsters is way way over the top. The IE team can take credit for plenty of bugs, but they can also take credit for some pretty neat things as well.