There's a big downside here too: by publishing lots of very big and crufty (and ill-thought out) API's, they make it very hard to come up with alternate implementations. And once devs are locked into those API's, it's very very hard to port things to a different engine.
So you might respect XmlHttpRequest, but it's also a fairly small API in comparison to some of the other things MS produced.
And it's _those_ things that are "possible" in IE that were precisely the problem. If your API consists of little more than exposing coincidental implementation details, of course lots of things are possible. They're just impossible to maintain afterwards in the face of any change.
TBL was against it, as were others. If he went through the theoretical 'standards' process that you infer is the 'right way' it never would have got done
I am definitely of the view of software first, standards second - because it has been proven throughout history to work
I believe this was the reason the WHAT-WG was started. The discontent of browser developers of the slow moving standardisation process of the W3C.
From the WHAT-WG FAQ:
"The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born."
So you might respect XmlHttpRequest, but it's also a fairly small API in comparison to some of the other things MS produced.
And it's _those_ things that are "possible" in IE that were precisely the problem. If your API consists of little more than exposing coincidental implementation details, of course lots of things are possible. They're just impossible to maintain afterwards in the face of any change.