In March I wrote a post titled IE8: The Bad, since then a new beta of Internet Explorer has been released. It still seems a bit dubious whether they are actually committing to standards. This could be a communication issue or actually intended. It is mostly unclear to me.
XDomainRequest: Microsoft unfortunately continues with XDomainRequest rather than making changes to XMLHttpRequest as other browsers are doing and as is being standardized by the W3C Web Apps Working Group. (Disclaimer: I am the editor of XMLHttpRequest Level 2.)
Some agreement was made to at least support the same protocol on the server, namely using the Access-Control-Allow-Origin header as per Access Control for Cross-Site Requests. (Disclaimer: I am the editor of that draft too.) However, IE8 only supports * as value for that header, not an origin, e.g. http://annevankesteren.nl (test). Sunava pointed out that was because the W3C WebApps WG was still debating the matter. Here is hoping they will fix the bug as there is agreement on that syntax.
HTML5 DOM Storage: localStorage and sessionStorage are now supported. Enumerating through them does not give the results I was expecting (I got "length" and "remainingSpace" back as well, besides the keys) and they still have a remainingSpace member that is not part of HTML5. Given that anything that gives some indication of space is highly vendor specific as it depends on encoding, compression, and type of device, they should really rename it to msRemainingSpace or some such or simply drop it.
IE8 also supports an event named storagecommit that is not part of HTML5 which tells you when the data has been written to an XML backend format IE8 uses. The event object for used for the storage does not expose key, oldValue, and newValue. The url member is named uri and the source member is null rather than a reference to the Window object. Ouch!
ARIA: Aaron Leventhal recently blogged about how ARIA in IE8 is a pain. (Aaron works for IBM making Firefox and Web applications accessible and is a member of the W3C PF WG which standardizes ARIA.) In short, when IE8 renders in super standards mode ARIA will work as everywhere else, otherwise you have to use Microsoft proprietary syntax. So not only do you need to upgrade your application code to be keyboard accessible and ARIA-enabled, you will also need to upgrade it from quirks to standards mode. Alternatively, you could take the easy way out and lock out other browsers. Not nice.
I should note I only played around with Internet Explorer 8 for an hour so I only discovered the most trivial interoperability issues. More extended testing would undoubtedly reveal more and I hope (independent) Web developers will try to verify what they are told.
As I explained in Aaron’s post, getAttribute doesn’t really exist in IE prior to IE8 mode. There, getAttribute is only another notation of getting the property value, and you have to use the property name; other examples of this are e.g. div.getAttribute('className') and input.getAttribute('htmlFor'). You just don’t happen to notice this for most attributes because they don’t contain a dash.
So the described behaviour is entirely consistent with previous versions of IE. This behaviour of getAttribute is a pretty fundamental flaw, and it seems understandable that the IE team did not want to risk backwards compatibility while still making ARIA available in quirks mode. I’m sure that had they not done that, there would have been complaints as well :).
In pre-IE8, if you want to get attribute values by their real attribute name, you can use the following:
function _getAttribute(oNode, sName) {
if (oThis.browser_ie) {
var oAttr = oNode.attributes[sName];
return oAttr ? oAttr.nodeValue : '';
}
return oNode.getAttribute(sName) || '';
}
This should work for the ARIA-attributes as well.
XML backend format? An excellent idea!
localStorage["foo"] = "bar";
<root><item name="foo" value="bar" ltime="3543985872" htime="29960568" /></root>
localStorage["foo"] = "\uffff";
<root><item name="foo" value=" /></root>
Oops.
Laurens, yeah, I think most people realize why it works the way it does. It just sucks a lot given that ARIA almost entirely consists of hyphenated attributes and Microsoft never gave feedback in the direction of that being a problem.
Yes, it would have been better if they had done that :).
@Philip Taylor: hmm, so MSXML uses U+FFFF as an end of string terminator? How odd.
Laurens: No, they use U+0000 as a string terminator (or at least if you write a string containing U+0000 into localStorage then everything after it gets stripped off). U+FFFF is just an arbitrary choice from the characters not allowed in well-formed XML (along with U+FFFE, U+D800, U+0007, and loads of others).
It looks their XML serialiser prints up to value="... and then aborts when it detects an invalid character, not getting around to printing the closing ", and then tries to close all the open elements before stopping, and then IE happily writes the broken output to disk and deletes the previous storage file and loses all your data.
(But I haven't tested this in any detail, so I may be missing some subtleties.)
So someone raised a bug with IE for this, right?
I did not submit any bugs. There is something you need to agree to which you cannot really do if you compete with Microsoft as I understood things. (Have not checked that though, but it scared me away.)
Looks like they'll never learn. Instead of implementing existing standards, they invent their own... History repeating itself.
Btw, IE8 is said to support CSS pseudo-elements such as :before and :after, however it adds an extra space before actually 'parsing' them... Which in most cases defeats the purpose.
Anne, read this: http://blogs.msdn.com/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx. Search for Content-Type. Fun ! Instead of fixing their broken content sniffing which has caused headaches for all other spec compliant browsers, they add yet another proprietary http header to override their behavior.
Do you really believe that ARIA only working in super standards mode is an issue? Since this is the default mode for IE8, this seems like a good thing. In effect, the people who are opting out of using well-defined web standards need to give them all up. This doesn't seem like all that bad of a thing to me.
It also works in other modes, except that there it does in proprietary ways, which would create issues for other vendors. So yes, I think it is an issue.
IE8b2 can not even understand a simple hover transition. And the missing content bug! They sure do know how to make IE really bad. Well done MS for keeping us developers amused.