Thursday 6 March 2008
Initial IE8 Thoughts
I just finished digesting the interesting-looking IE8 whitepapers. Some thoughts...
The IE team has obviously worked really hard and made a lot of good decisions. Good on them.
The Good News
They're fixing zoom to work like Opera and Firefox 3. Makes sense.
They're doing WAI ARIA support, great for the accessible Web.
They've implemented some HTML5 features! In particular, navigation, storage, online/offline events, and postMessage. Interestingly, as far as I know, they've only provided public feedback on the last one. I'm really glad MS has opened the door on HTML5.
Acid2 support, of course, including the data: protocol and fixes to <object>.
Selectors API support is good, we need to get down and implement that.
Making tabs run in their own processes is probably a good architectural move, but it will be interesting to see what that does to footprint.
Outlook Mixed
The "CSS 2.1 Compliance" whitepaper has the interesting sentence
In this vein, Internet Explorer 8 will ship with an additional layout engine that is fully compliant with CSS 2.1 upon final release.
That is a rather strong statement... Are they really promising to have no bugs? That whitepaper is also incomplete; if they're planning full 2.1 compliance they'll need a number of features not listed. Their list of CSS3 features is also very short, consisting really only of 'box-sizing' (since they already supported 'writing-mode'). I assume they're doing more here that's not described in the whitepaper yet.
They've done work to deal with DOM-JS cycle leaks, which is great for Web developers and users. But there's a very strange sentence in here:
This feature may affect the behavior of Web pages that depend on garbage memory that, only as the result of a memory leak, existed in previous versions of Internet Explorer. In Internet Explorer 8 Beta 1 for Developers, these pages will reference unallocated memory and generate a fault.
Web pages should not be able to reference unallocated memory and fault, that is a browser bug. Memory should not be collected as long as it's accessible to a page. Maybe they're talking about trusted Web pages using ActiveX controls that keep pointers to DOM objects?
They've done some work on developer tools, but it just looks like a partial Firebug clone. They'll need to do more to catch up there ... but we'll need to do more to maintain our lead. Yay for competition!
The Bad News
The untold story here is what's missing. Obvious omissions that the other major browsers have already shipped --- no SVG, no <canvas>, no JS setters/getters, not even DOM2 Events.
Their implementation of XML namespaces is supposed to be improved but it's still badly broken and they know it. I wonder why this wasn't fixed.
They've introduced their own cross-site XMLHttpRequest-alike, when the W3C is in the throes of standardizing cross-site extensions for the regular XMLHttpRequest. That's bad form. Likewise, "Activities" really needs a cross-browser spec; it would be good to get spec coverage and feedback before releasing a beta.
As I suspected, interacting pages in different compatibility modes creates really nasty problems, so there's even a whitepaper dedicated to it. It makes me feel sorry for the IE team, but it will also complicate things for Web developers.
One thing that really ticks me off is that the IE messaging is very very careful to never mention any other browser. I know it's standard practice but frankly, it's rude, especially in relatively technical documents and blogs. Would it kill them to mention which features they're adding have cross-browser support?
Looking Ahead
Some of the things I thought might be there aren't, or at least they're not talking about them yet. Their CSS3 grid proposal isn't mentioned. There's no talk about WPF or DirectX integration (beyond what IE already has), although that may be felt to fall outside the scope of IE8 proper.
Implementing a big feature list is only a first step. The real test is to follow through with careful testing and bugfixing, especially for interoperability. Careful tracking of specs as they evolve before IE8 ships is also going to be important.
Comments
Anyway, thanks roc for putting into words what I was feeling reading the release notes and web pages. The lack of a nod to other browsers is, quite simply, rude.
that's a bit harsh/negative? Surely that's great news.
What indeed is actually wrong with cloning Firebug for IE? My web development job would be extremely easier if I had access to firebug in IE.
I develop with Firebug and use IE View to check IE compatibility. When IE screws up, where do I start debugging?
Yes I know debugging existed before Firebug, but I don't want to remember those dark horrid evil days!
I *think* the HTTP spec says you should only have 2, but these days a tiny bit more (too many may lead to other problems for the browser, maybe) seems reasonable.
Is this something useful for Firefox and other modern browsers, do you think?