Internet Explorer 8 is final now. Seems about time to update the update on the state of IE8 and standards support.
As expected, XDomainRequest is still there. They have updated the API support for the server though and now accept Access-Control-Allow-Origin containing an origin. Yay! (Part of Cross-Origin Resource Sharing.) They also fixed support for ARIA in the DOM. Also yay!
Mode switching is also still around. Henri Sivonen has detailed information on IE8 Complications. Not a pretty sight. If you do not use their proprietary X-UA-Compatible flag you are left over to black magic. Way to go Microsoft for adding useless cruft to servers all around the globe.
Web Storage support is also somewhat troublesome. Google fanboys take note by the way, storage is no longer part of HTML5, no matter what marketing tells you. It’s a separate draft now. (Don’t read too much into that URL ;-)) The following from Web Storage was fixed in IE8 final:
uri member has been renamed to url as per the specification.
The following is still broken or wrong:
remainingSpace attribute and a storagecommit event. Microsoft agreed to rename them to something like msRemainingSpace and msstoragecommit, but have not done that.
storage event is dispatched on the Document object rather than the Window object. You’d think that the basics would be the least of potential interoperability issues. Guess again.
key, newValue, and oldValue members. source is still null rather than a reference to the Window object.
Maybe I should start touring around the world charging a lot of money to tell QA how to read specifications. Sounds like a great job. Not really.
You can make a lot of points with XKCD. Never surprised to be reading a dev blog of any kind and hover over a link to find it goes there :)
Maybe it's just me, but I think most of your points are small, non-issues rather than anything that will really affect adoption or usage. Implementing an interface only guarantees that you'll definitely implement a set of properties and methods, it doesn't preclude the addition of other properties and methods, so I don't see why MS adding a few additional properties is all that big of a deal.
Also, not sure the firing of the event on document vs. window makes all that big of a difference, either. IE's events have always just bubbled up to document and not window, so you could argue that they're being consistent. I'm actually not sure that this event is all that useful anyways. It seems like if I'm storing some data, then I'm already aware that this is happening.
Despite that, I do think it's lame to only half-implement events. But I don't think you can take all of this and say that IE's implementation is troublesome. It's still complete enough to be useful.
The issues can be worked around, sure. Still, the specification is clear and misimplementing parts to this extend is troublesome in my opinion. Adding proprietary features is somewhat ok, but they should have prefixed as they said they would to clearly indicate these are Microsoft-only features and not something Web authors should rely on.
The event is useful if your application is opened in several windows at once by the way.