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:
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
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:
.ownerDocument– Finally we have a unified way of dealing with iFrames.
getElementByIdreturns elements by id – ONLY. Been such a long time coming, thank goodness.
getAttribute("checked")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.
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.
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.
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.
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).
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.
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.