The vision behind Internet Explorer 9

Having lost ground to rival browsers in recent years, Microsoft is pulling out the stops for the development of the next version of its browser, Internet Explorer 9.

The company has said that the browser update will deliver "interoperable HTML 5". It has also promised better performance, which will come from hardware-accelerated layout and rendering, support for Scalable Vector Graphics (SVG) and a new JavaScript compiler. These are steps meant to ensure that Internet Explorer is ready to work with the next generation of the web, which will rely on new standards like HTML 5 for marking up pages and a new version of Cascading Style Sheets (CSS3) for formatting.

Earlier in May, the company released the second platform preview of Internet Explorer (IE) 9, giving developers an early look at the browser, which does not yet have a schedule for release. ZDNet UK talked to Dean Hachamovitch, the general manager of the Internet Explorer team, to get an idea of Microsoft's vision for IE9.

Q: What exactly is the IE9 developer preview?
A: This is a minimal wrapper around the Internet Explorer runtime. It's got a title bar [and] a couple of dropdown menus, but it's not a full-fledged browser. There's no back button, no malware protection... and a lot of things we're planning are deliberately not in the preview. However, it is a full exercise of the platform, with hardware-accelerated rendering, SVG graphics and the new script engine.

We're committing to update it approximately every eight weeks on the way to beta. What we want is to deliver this more often than end user-directed browser betas, and it's easier to release the platform bits without a user interface wrapper. We're trying to accelerate the feedback loop, and the preview is a large part of that.

There is heavy lifting going on in the user interface and experience space, as well as in the platform, but we're not talking about that yet.

What is important for IE9 to deliver in terms of HTML 5?
Reading the HTML 5 specification, what struck me is the opportunity HTML 5 applications will have to do things. We had the opportunity to think how will this go, how will it stress these systems, how is it going to stress the internet. This stuff is really going to need the hardware in ways HTML applications and Ajax applications don't.

How are you going to deliver that performance?
There are two big chunks of the browser where [the browser] spends its time: JavaScript and rendering. I just want to get this stuff on the page, and it turns out GPUs are really good at this.

There's a new JavaScript engine that's really, really cool. In addition to a having a faster interpreter, it has this alter ego in which it is a compiler. Unlike other things you experience on the web today, it operates in the background. You get all the benefits of the compiler, but you don't have to wait for it.

When you have modern hardware that has multiple cores and even your Eee PCs have modern hardware; when IE9 spins off and says "I want to run in the background" — page content doesn't have to wait.

Does the GPU make a difference on basic PCs?
We showed this on a $460 (£319) Asus 'nettop' running Windows 7. It has 2GB RAM and an Atom chip, and it has this graphics chip hardware decoder that's a little something special. [We were showing it] with HTML 5 video, HD-encoded video... we're showing hardware-accelerated video just playing off the hard drive.

With Chrome, the CPU is going "I think I can, I think I can, oh my God, I'm dying..." The machine is going all out and this is the best it can do. In the IE9 preview, we have two HD-encoded videos playing — that's 'playing', not 'one of them is dropping frames and the CPU is waiting for you to do something'.

When you talk about interoperable markup, how is that different in IE9 to other browsers?
One thing I want to point out is the idea of 'same markup'. We've heard so consistently from developers that they want to write the site and they want it to just work. The drive behind having that same markup work consistently is huge.

One example is getting borders right. That's like the poster child — if not the centrefold — of how developers want the same thing to just work.

We have great examples of...

...where the same markup does radically, painfully different things — not just between IE and other browsers, but between other browsers, and even between different versions of WebKit. Of the five [other] browsers, two of them are WebKit based. We looked at the same [SVG] in both, and one was square and one was round — they're not even on the same page just yet.

Other browsers have already implemented parts of the proposed HTML 5 spec. Why have you waited till now?
The challenge is that you become a moving platform and stuff doesn't work. An influential leader in the web developer community said to me, "It sure seems premature for folks to declare that they do '[an arbitrary] name of standard'. How can they say they support CSS3?"

[Let's say] my website works today. [Then the browser maker issues] a new daily build, and it doesn't work anymore. Am I supposed to change the site? You end up in a 'full employment act' just making the site work with all the builds, and it doesn't leave you time to innovate, to do things that are good for your business.

We're calling out that there's this problem [keeping abreast of standards] with every browser. It's not like there's this happy bubble world where everything interoperates and IE is over here. Look at all this stuff people have to do to make these other non-IE browsers have rounded corners.

It's not like there's this happy bubble world where everything interoperates and IE is over here.

But won't this be resolved whenever the HTML 5 spec is agreed?
Probably not. Based on conversations I've had with some of folks who work on some other browsers — not to speak on their behalf — I will suggest they might not have a timeline for removing some of this stuff. And when they do stop requiring it, there are still going to be a kajillion websites that have it. Do we keep supporting this old stuff with these extra tags?

Is Microsoft trying to speed up the HTML 5 conversations or slow things down?
Frankly, we're trying to cover the important parts with quality in the most timely way possible. I say that as an engineer: it's not up or down, faster or slower — it's about [getting it] right.

You've criticised the Acid3 test, but you've also said that your Acid score will improve. How valuable is the test, in your opinion?
As we support more of the markup that everyone is really trying to use on the web, our Acid3 score will go up. As to the test... a lot of people seem to be running it. Acid3 is a proxy that many people use for standards compliance. There are many different ways to assess standards compliance. As standards change under construction, as other browsers change, you see a lot of the variance.

As an engineer, it's interesting to call something an acid test and then not call it really an acid test. You can have a score of 100 on Acid3 and completely mess up these borders I'd want to use on my page; if I can score 100 and the same markup fails, maybe there's a problem in the test.

Everyone wants a test that is worthwhile. There is a conversation on the mailing list as to whether the next acid test should be a W3C thing, and there's a very real possibility that indeed this would be an industry-backed standards-based test.