Travel Plans

Lately I've been flat out working on various Firefox 3 blocker bugs. Overall I think layout is in pretty good shape although contenteditable still needs more love. Bugs involving rounding during rendering have also been hard to eliminate, poor Vlad's just about reached the end of his tether :-). On the bright side, the layout regression reports that are trickling in are all very minor, and MathML is just about up to scratch. I also get the feeling that there's been an uptick in new contributors during the last few months. Over the whole product, I've got the best feeling about this release that I've ever had.

[One of the trickiest bugs I worked on recently turned out to be partly due to a regression in cairo's "pixman" library. I was pretty annoyed until I had a John 8 moment and thought about the amount of pain my bugs and regressions must have caused Web developers over the years. Ouch. Sorry everyone!]

Next week, Wednesday to be precise, I'm travelling to Australia for three weeks. The first ten days are family stuff, but I hope to be online and working some of the time. After that I'm going to visit five universities to talk about Firefox and do some recruiting. The schedule is:

• Monday March 31: University of Queensland, Brisbane
  
• Wednesday April 2: University of Sydney
  
• Friday April 4: Australian National University, Canberra
  
• Tuesday April 7: University of Melbourne
  
• Wednesday April 8: Monash University, Melbourne
  

I don't have final times or room locations for most of the talks yet, but all those places should eventually have the information on their Web sites. I'm interested in meeting people, especially students, on and around those days.

The timing's not great, but there was no way to avoid the Firefox endgame except by waiting for it to ship and then planning the trip, which I didn't want to do. I should be able to get quite a bit of work done on the off days, and I'll be back with a vengeance on Thursday April 9 if there are any bugs left to fix.

NOT A Cross-Browser Implementation Of XBL2

This project may be cool, but it doesn't --- and can't --- make the XBL binding nodes anonymous, which is the single biggest feature of XBL. Without anonymous nodes you lose a lot of the modularity and transparency benefits, and because you smash the original DOM you cripple the ability of the client to manipulate the DOM after the script has been applied.

So what we have here is a DOM preprocessor which uses XBL2 syntax, which does sound cool and useful, but it's not remotely an "implementation of XBL2". The blurb on the project's Web site is very misleading. It's also misleading when people who should know better blog as if the claim was true.

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.