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.



14 comments:

  1. What about their half-arsed data: implementation? For instance, <a href="data:,this%20wont%20work">not supporting</a> the usefulness of being able to create a URL on the fly for a vcard and presenting it like a file massively limits offline support imho.

    ReplyDelete
  2. My biggest disappointment is no JS getters/setters. I think there are work-arounds for most of the deficiencies.

    ReplyDelete
  3. What’s even more strange about that is: they do support VBScript getters and setters. And you can access VBScript objects from Javascript.

    ReplyDelete
  4. It's pretty ironic how Mozilla have just decided to extract the DOM inspector from Firefox, and along comes IE8 with (as far as I can tell) a very similar tool. :)

    ReplyDelete
  5. My biggest disappointment is obviously SVG.
    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.

    ReplyDelete
  6. "but it just looks like a partial Firebug clone"
    that's a bit harsh/negative? Surely that's great news.

    ReplyDelete
  7. Dean did plenty of nodding in his keynote though...

    ReplyDelete
  8. "just a .. firebug clone" ????
    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!

    ReplyDelete
  9. Robert O'Callahan7 March 2008 11:57

    I didn't say anything was wrong with it, but cloning Firebug shows a certain lack of imagination. There's a lot more that could be done to improve Web development and debugging. Hopefully Mozilla will be able to do some of it...

    ReplyDelete
  10. Some good observations. I was interested to read them say they would help increase parallel downloads by allowing 6 concurrent HTTP connections to the same domain. (Or something like that).
    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?

    ReplyDelete
  11. Umm.. ok. Firebug has been getting tons of praise, and then when IE does something similar that's lack of imagination? Isn't it simply the best developer tool around, and the best way to do things?

    ReplyDelete
  12. Hmmm... you can probably ignore my previous question about whether Firefox and others will follow suit on the number of connections increase -- I believe you all support 8? I missed that... IE really is catching up more than I thought :)

    ReplyDelete
  13. Robert O'Callahan7 March 2008 22:04

    There are a lot of ways browsers can help Web developers beyond what Firebug provides. So Firebug is not "the best" way to do things, although it may be part of the best way.

    ReplyDelete
  14. I just hope they'll soon include APNG support...

    ReplyDelete