Our day has finally come. CSS coders got some love with Internet Explorer 7 – us JavaScript folk got absolutely nothing. In fact, at last count, all we got were a couple new bugs to deal with (file:// requests not working via XMLHttpRequest and <object>.getElementsByTagName(“*”) always returning no elements).

Internet Explorer 8 is our release.

The first beta was pushed out today and it shows huge promise. It’s already achieved way more than I would’ve expected and it’s made me hungry for more. If you had bet me that Microsoft would be mentioning the phrases “ARIA”, “SVG”, and “MathML” in their release notes I would’ve lost.

Here are my thoughts on a bunch of the browser features:

W3C: querySelector

A super-fast way of finding elements based upon a CSS selector. The second browser to implement the selectors API has hit the market (behind a WebKit nightly release).

It’s important to realize that any selectors here are completely reliant upon the browser’s native selector implementation. IE8 is only shooting for CSS 2.1 support – which means that you really shouldn’t be holding your breath for CSS 3 selectors. As I mentioned previously these blackbox APIs are going to be a source of never-ending hair-pulling and struggle going into the future.

HTML 5 Party!

I was hoping for some HTML 5-compliant features to land – well, hoping isn’t the right term, perhaps ‘feverishly expecting the worst’ is more correct. However we can see that we’ve been graced with 4 full feature implementations from the spec – fantastic!

HTML 5: window.location.hash

Already supported fairly well by most browsers. Modifying window.location.hash changes the page URL and adds the page to the history (allowing for back-button simulation in Ajax applications). IE went a step further and broadcasts the hashchanged event (the first browser to do so, as far as I know).

HTML 5: DOM Storage

A feature that I discussed previously in which data can be persisted in a way that supersedes the use of primitive cookies storage. This has been in Firefox since version 2 but is absent from Opera and Safari.

HTML 5: postMessage

As I discussed previously postMessage serves as a way of communication across frames with simple text strings. IE 8, Opera 9, Firefox 3, and WebKit nightlies all support this feature – making it the only one with complete browser support.

HTML 5: Offline Events

As I’ve written about previously this is an easy way of detecting connectivity within the confines of JavaScript. With it we can write graceful offline Ajax applications. Firefox 3 and IE 8 appear to be the only browsers to support this feature.

XDomainRequest

This is an interesting feature for doing cross-domain requests but doesn’t appear to conform to the existing Cross-site XMLHttpRequest work which is in Firefox 3. Even at that it appears to be quite crude – forfeiting any form of filtering or security controls for a simple boolean “yes/no” header.

Seeing this new API concerns me. The Cross-site XMLHttpRequest work may be in some flux, as some API points are still being hammered down, but it’s doubtful that the resolution will end with something identical to what’s being described by Microsoft.

DOM bug fix love

getAttribute/setAttribute have seen a major overhaul – in short: They now behave like they should and as they do in every other browser. The notorious issue of accessing relative/absolute href/src attributes is also resolved – which is just great. They also saw fit to add hasAttribute.

Also newly fixed/added:

.ownerElement and .ownerDocument – Finally we have a unified way of dealing with iFrames.

and – Finally we have a unified way of dealing with iFrames. getElementById returns elements by id – ONLY. Been such a long time coming, thank goodness.

returns elements by id – ONLY. Been such a long time coming, thank goodness. Doing getAttribute("checked") now returns “checked” instead of true.

now returns “checked” instead of true. <button/> values are actually submitted now, instead of their inner text values.

Dynamically created (or modified) radio buttons are now checkable.

I simultaneously feel both joy and anger in seeing these fixed. Happy that they’re being released and anger for the fact that I had to struggle through them and that they now consume some portion of my brain.

W3C: Events

This is one area that is completely absent from this beta. We are still stuck with IE’s attachEvent system – no addEventListener in sight. I don’t know how serious they are about supporting Acid3 but it includes a test for addEventListener so they may want to consider it extra strongly.

I can partially understand their desire to keep their existing API but I don’t understand why they have no interest in, also, adding addEventListener , etc. to complement what’s there. I assume it’s because they would now have to support concepts like event capturing.

I’m really disappointed with this. This should’ve been a top priority fix before implementing new psuedo-XHR systems like XDomainRequest.

JavaScript Language

The IE team has made some big improvements in improving garbage collection issues, memory management, and performance – all of which will be greatly appreciated in everyday applications.

Although, I mis-spoke slightly earlier: While IE8 is been great for JavaScript developers I was implying “JavaScript + DOM” developers. For pure JavaScript it’s completely frustrating: There doesn’t appear to be any new pure-JavaScript features in this release. I can only hope that we’ll see more in a future beta release.

ARIA Support

This one completely blew me away. ARIA is a fantastic specification for empowering web applications with the ability to clearly communicate their intentions to a screen reader. The biggest hurdle with the effort, up until this point, has been the lack of IE support – obviously this will no longer be the case. Firefox, IE, and Opera all support ARIA now. The WebKit team doesn’t appear to have interest in implementing this feature, which is a real shame.

Embedded SVG

Support for embedding namespaced elements within XHTML is now possible. This means that you can now do inline markup for SVG and MathML, amongst others, and have it “just work” (as long as you have their associated plugins installed). It’s probably a bit much hoping for native SVG support, but I’ll take what I can get.

Firebug for Internet Explorer

We finally have a heavily-Firebug-inspired tool inside Internet Explorer. To quote Joe Hewitt (creator of Firebug): “I couldn’t be happier that Microsoft completely copied Firebug for IE8.” I have to agree – a tool like this has been a long time coming and it’s greatly appreciated. Only the Internet Explorer team would’ve ever been the ones to build this tool – there’s simply too much information here that’s unavailable to typical IE extensions.

Browser mode toggling

At first glance this feature makes the most sense for seeing if your IE 7 page will work ok in IE 8. In actuality, however, this will end up being very useful for developing a standards-compliant page (in IE 8, FF, Safari, Opera) and then toggling to see what the result is like in IE 7. This is so much better than the IE 6 to IE 7 jump where you have to keep your browser in a virtual machine in order for it to run side-by-side (according to Microsoft, at least – even though there were standalone solutions).

Bug Feedback

The Internet Explorer team is collecting feedback from select beta testers and publishing the bugs on a publicly-accessible site. This a huge step in the right direction (going from no communication to some is great). “Common” users are forced to vote for their “favorite” bugs to try and catch the eye of an IE developer. It’s a strange situation but one that shows progress, at least.

Conclusion

In all I’m positive about this release, even with all the ups-and-downs. Seeing features like querySelector, ARIA, and postMessage helps to warm my frosty, bitter, heart. While there’s still some major faux-paus in this release (no new JS langauge features?, no W3C events?, no CSS3 selectors?) I think we can, at least, be excited to see what happens in the next beta.

If nothing else the Internet Explorer team has done a great job of tackling many of the expectations of the development community – if they continue this trend I don’t think anyone will be left disappointed.