By: Kevin Yank

December 10th, 2007

Reader Rating: 5

At Web Directions South this year, I had a chance to talk with Chris Wilson, who needs no introduction. He's the Platform Architect for Internet Explorer at Microsoft. You can listen to this interview [1] if you prefer.

SP: Hi Chris.

Chris Wilson: Hi.

SP: I've heard a couple of your talks in the past year, and the common theme that I'm hearing is that you're trying to put developers in the shoes of you guys at Microsoft, and the realities that you have to deal with in developing Internet Explorer.

Chris Wilson: Mmm-hm.

SP: Why do yo think among developers and designers in particular at the moment Microsoft has such a bad reputation?

Chris Wilson: Well, I think that a lot of the designers and developers out there have looked at the platform that we have today and some of the problems that didn't get fixed for a number of years, and were very frustrated because they had to work around those problems, and spend a lot of time working around those problems in some cases. And I think that the one thing that I believe now, actually, for the last six months or so we've really gotten very positive response from the release of IE7, from exactly that kind of constituency. You know, I talk to people all the time who-- I'm actually really pleasantly surprised that they say, you know, "I was really upset about working with IE6, and I love IE7." You know, "It's not everything that I could ever ask for, but it really is everything that I needed, and everything that makes it so that it's a lot easier for me to do my job."

SP: Oh, absolutely.

Chris Wilson: And that's exactly what we were shooting for.

SP: No browser release - and particularly, no single browser release - was going to give you everything you absolutely wanted, but certainly-- Yeah, I want to make a point of saying "thank you" for the focus, especially on adopting and supporting standards in IE7. That absolutely needed to be done.

You mentioned towards the end of your talk, Web 2.0 was changing some of the assumptions that were having to be made. Can you share any details about exactly what that's meaning to the next version of IE?

Chris Wilson: It's not that it's changing specific features that we're doing. It's more the scenarios that we need to optimize around, both in, you know, what APIs and features we offer and what the performance those features are tuned for, and that sort of thing. It's the way that people program for the Web, that they build web presences, is just different than it was five years ago -- ten years ago, certainly, but even five years ago. It's just different. You didn't have, you know, heavily interactive JavaScript apps that were very common, then. There were certainly some of them out there, but they weren't, you know, the front page of nearly every site you go to, which I think in a couple more years it will be.

SP: Yeah. So, you took a moment to say, "Yes, we are working on the next version of Internet Explorer." Immediately after Microsoft announced they were working on Internet Explorer 7, we started seeing-- You know, we had the launch of the IE Blog. We started seeing, not detailed roadmaps, but some initial things about, "These are the top of our list of what we're going to tackle. And even the things we can't tell you about, this is our reasoning for what we're taking on." And we haven't really seen that about IE8. Is it too early?

Chris Wilson: Well, one of the things that we wrestle with at Microsoft is pre-announcing - like, announcing before we're really, really confident that we can ship something with really high quality when we say we'll ship it. And because we're such a large company, because we ship to so many people-- And it's not-- When I say that I don't really mean "because we ship to so many end users," which we do, but we ship to so many corporations, and so many other businesses. Really, you know, we set the pace for a lot of other businesses. When we ship a new version of Internet Explorer, a whole lot of companies have to go test their software against IE, they have to go, you know, figure out what kind of content their tools should be generating, and that sort of thing. And because we do that, because there are so many people who rely on us, we have to be very, very careful to be 100% confident when we announce things like "that's exactly what we're doing," or "that's the date that we are aiming for." When we don't, we tend to get a lot of people upset with us, of course, but it's not just them being upset with us; it's actually, it can be damaging their business model if they bet on us releasing something in a given timeframe, or bet on us releasing a given feature, and we don't ship it.

SP: You did mention that you are-- or your team is building a whole new rendering engine for the next version of IE, and I'm sure a lot of people will wonder, you know, there's Gecko, and there's WebKit, and they're open source, and they're great! Is there really a point to Microsoft building a whole new rendering engine from scratch right now? Is it just the licensing issue?

Chris Wilson: Absolutely not, for a couple of reasons. The first one is, we're not actually building a whole new engine, like the whole-- In IE, our component was code-named a long time ago, 'Trident.' It's kind of the rendering engine and the object model and the parser -- all of these pieces pushed together. What we're actually focused on right now is specifically the layout engine part of that, the part that figures out how to lay out text, content, you know, borders, etc. on the screen, and be able to manage text flow in general. This is an area that there's a lot of detail on in the CSS 2.1 spec, and, you know, we started the one that we have quite awhile ago, and we realize that we could keep fixing it, we could keep doing things to it and adding more features, because we actually do have a number of features that we never completely utilized what we really could out of them. For example, in IE5.5 we introduced this templating technology to do pagination for printing, and we have these ideas of using this in onscreen scenarios, but we never got around to it. So we could've done that, but we really looked around the company and we realized, you know, "Wow, we are Microsoft. There are a lot of people here with layout expertise. There are a lot of people who really know how to do layout right." And because we hadn't really gone in and done a major revision to this code for many years, wow, we needed to unchain those people and, you know, really allow them to do some really incredible things. I think that you'll probably see when we release why we did that. There's a lot of benefit we can really set ourselves up to do some amazing things in the future. And that doesn't mean that the first release will do all of that, of course, you know, like anything else. But it's enabling us to do some really great things in the future.

As for building on WebKit or Gecko or any of the other engines, part of that I'm sure probably is that we would have to leap through some licensing challenges there. But, the biggest reason for me is that there's a real responsibility when we ship code, particularly to half a billion people, and we would be taking on that responsibility for a set of code that we don't own, we didn't come up with it, we're not experts in it, and there's a lot of code there. But we're blamed if something goes wrong; even further than that, we're responsible for it if something goes wrong. So, you know, if there's a security exploit, we have to go fix it, we have to go deliver the fix immediately, or it's-- we're on the line for that. And that makes it a bit challenging. And when I look at the other toolkits out there, I think that on the amount of work that they've put in to completing some standards work or, you know, taking on a bunch of different standards that we haven't gotten to yet, I think they've done some great things; I don't think it's so great that the only answer really should be, "Let's go take that engine." One of the things that I know that I really would like to see from the standardization side of my job, you know, from my HTML Working Group co-chair, and kind of co-ordinating our other standards involvement -- One of the things that I would point out too is that, really, the more implementations that you have that work differently, the better you make your standards. Because, otherwise, you end up just relying on one implementation to define what the standard is, and in a way that sort of happened with IE for awhile. Before that, it absolutely was happening that Netscape defined what the standard was. I mean, we had to be compatible with Netscape, because that's what people wrote their content to. So I think that having multiple implementations is really a good thing; that's why the W3C requires it.

SP: You mentioned your five hundred million users, and you've spoken a lot lately about how that's the driving force behind Microsoft's obsession with maintaining backwards compatibility. How much of that need to preserve backwards compatibility, specifically in Internet Explorer, comes as a result of this age-old thing that you can only have one version of Internet Explorer installed on a system at once?

Chris Wilson: Surprisingly, very little, because the challenge for us really is not that we can only allow one way of doing things. Although actually doing totally side-by-side different versions of IE is very hard, it's quite easy for us to go in and introduce separate code paths for, you know, the old way of doing things and be compatible. The problem is knowing when to switch that on, knowing which path to use for any given piece of content. This is really the key to our compatibility challenge, and, you know, when I say that in the future we'll have to ask authors to opt in to standards compliant behavior, it's basically this-- when we get a web page from out on the Web and we start parsing it and try to render it, we don't know how standards compliant that code is. We really don't. There's no way to tell how standards compliant that code is. And that means we don't really know which set of behavior we should follow. So I think that, if you're expecting the user to do that, the user doesn't know, right? When I go to a web page, I don't want to have to say, "Oh, it doesn't look right, maybe I should try the old rendering engine." I don't want to have to force people to flip back and forth between different browsers, either. Certainly, if we did allow multiple versions of IE to run side-by-side on the same system, you still have the problem of, well, you click on one link and it needs to get opened in one engine, and you click on another link and it needs to get opened in the other engine. It would be a real challenge to browse that way. The user model would be pretty confused.

SP: Yeah. And yet, at least until now, the competing browsers like Firefox and Opera and things like that really have gone on a 'user decides what the rendering engine they want to use is,' even if it's just by choosing when to update to the latest version.

Chris Wilson: Well, the user chooses which browser to have, you know.

SP: Yeah.

Chris Wilson: And you can side-by-side some of the other browsers, although sometimes that causes some issues too. But I think you would find that that is a good thing for web developers. Web developers need that sort of ability to run multiple versions on a single machine. That's really why we went down this path of, well, "What's the best way to do this for us?" The best way-- Like, even if we solved the problem in IE today, that doesn't solve the problem for past versions of IE. We can't actually go back and change the code to make it work side-by-side, because if we did it wouldn't be IE6 anymore, it would be some mangled version of IE6. But that means that we could only solve it in the future. We don't really want to just solve it for the future. The best thing we could do was provide virtualization technologies to make that happen, which is why we went down this path of, "Hey, let's go figure out how to give a free virtual machine of Windows XP, and a free virtual machine that, you know, has IE6, and one you can upgrade to IE7."

SP: Which was huge, and I think that's a lot why the common criticism of "Why can't I install more than one version of IE?" has really gone away, because that was a criticism that was coming from the developer community.

Chris Wilson: Largely, yeah. But the challenge here is that, you know, when you think about normal end users out there, they don't really want to think about even running multiple different browsers, let alone multiple different browser versions. They just want the Web to work, right? They want all these browsers to be interoperable, and to have it all work.

SP: The tantalising thing, though, that this developer opt-in model prevents is, what if we could get all of that old web content displaying on a new rendering engine? What possibilities would that open up? Just because a site is no longer being actively developed doesn't mean that a browser extension that used the features of a new rendering engine couldn't make that old site sing in a new way. And that would be great!

Chris Wilson: But are you suggesting that a browser extension could take that old content and make it render through the new engine?

SP: Well, if that old content just happened to be standards compliant, or simple enough, or well written enough that it would display in the new rendering engine, it would be great to be able to take advantage of that, and the developer opt-in model sort of prevents that.

Chris Wilson: Well, but you already can do that, if you want. You could certainly write a plug-in that would force everything to be in 'standards mode' -- whatever the grade of standards mode there is at that time. I think the challenge really is going to be, that's not really the way web developers write content. Like, what they do is they write content -- and let's presume for a moment that they do write it exactly to standard. They start out with, you know, all the relevant standards printed out on the desk in front of them, and they write their content that way, and then they need to make it work. And the things that they do to make it work are frequently the most damaging things for us. They are, you know, applying hacks that cause problems in IE7, but were necessary to make IE6 render properly. And I think you'll probably find that for the other browsers as well. And sometimes it's because they have bugs, or missing features or whatever; somethings it's just that there's ambiguity in the spec, and they do it one way and the other browsers do it some other way, and you know, a web developer has to deal with that. They have to make it work the same way in all browsers, and that's the point-- like, if you could get the content that was perfectly standards compliant, and then just try to fix it from there, that would be great. The problem is nobody writes content that way, partly because a) there's no point for them -- they're not writing a standards test suite, they're writing a web page -- and b) they don't have anything to test it against to validate that they actually did do it exactly right according to standards, and that's the way it's going to look.

SP: One point that really stood out for me in your talk was that, in an ideal world, over time, the difficulty of adapting a standards compliant site to work in a new browser should to tend to zero over time.

Chris Wilson: Yes.

SP: Now, with this developer opt-in model that Internet Explorer and, if it goes into the HTML spec, all browsers will eventually adopt, are browsers over time going to have, you know, five, six, seven, ten, eighteen different rendering modes for each version of the spec that's released over time, or will this tendency of the differences to tend towards zero over time mean that one day this can go away?

Chris Wilson: I think that my personal hope, certainly, is that one day this gets to go away, that the differences between browser versions are not what we call internally 'breaking changes.' They're not things that really have the potential to break somebody who's written to them, and you are only adding things after that. I'm not sure if we'll actually get there, because I look at all of the standards that are there, in place, today, with CSS 2.1 and HTML 4.01 and, you know, what we're doing with HTML 5, and all of the other relevant web standards, and every single one of those standards is correcting things in the previous version. It's clearing up ambiguities, it's correcting problems. I would hope that the specs that we're writing today-- I know that the specs that we're writing today are much more declarative about what should happen. They're much clearer, they don't leave as much to the developer's imagination. And at the same time, I know that there are things in there that are not declared, and hopefully we'll be able to patch most of those holes before before we start shipping the standards, but at some point, you know, we're going to come up with an implementation that we think is right according to the standard, and then other people are going to come up with implementations thinking they're right according to the standard, and they are, because the standard doesn't make that decision. And this was something that we really did have a tremendous amount of problems with in IE, because we wrote our first implementation of CSS before there was a CSS 1 recommendation. And we wrote our second one, you know, shortly thereafter, I think, or actually, probably still before -- CSS 1 took awhile to get stamped. But, you know, we didn't have all of the things that CSS 2 did. We didn't have those specified, so those of us on the CSS Working Group at the time kind of had different pictures in our head of how the big picture fit together, and how those CSS 1 features were supposed to interact. So, you know, the way that we internalize that into code was a little different.

SP: You are the co-chair of the W3's HTML 5 Working Group.

Chris Wilson: Yep.

SP: Just how much email do you get from that list?

Chris Wilson: Well, I mean, anyone can join is the great thing, so you can find out for yourself!

SP: I have joined that list...

Chris Wilson: Honestly, it's a lot, and of course I have some-- My own work email probably is even more than that. But certainly that working group, I think, alone probably generates on average fifty messages a day or so.

SP: And you said you-- at least, one of the big reasons you were willing to take on that role was that you have a belief in open standards.

Chris Wilson: Mmm-hm.

SP: Has your experience so far as co-chair tested that belief, or reinforced it?

Chris Wilson: It certainly hasn't shaken my faith that that needs to happen, that we need to openly develop standards that can be freely implemented. I still think that's absolutely critical, and that's why I'm still there. There are certainly some challenges. This group is really, for the W3C, kind of an experiment in openness, and we're having some challenges with that. You know, there are a lot of different opinions, and it's hard to know what, in the end, should be considered consensus. What, in the end, should be considered fair? Which, of course, is a big challenge for me as one of the working group chairs. We have to work that out.

SP: I'm sure the other working groups, like the CSS working group, in the little spare time they have, are watching with interest.

Chris Wilson: I absolutely think so, yes.

SP: Great. Well, thank you very much, Chris for chatting with us...

Chris Wilson: Thank you!

SP: ...and, see you around.

Chris Wilson: Seeya!

Chris Wilson's talk from Web Directions South, "Moving the Web Forward" will be available for downloading in podcast form from http://webdirections.org [2].

[1] http://media.sitepoint.com/presentations/2007-09-28_wds07chriswilson.mp3
[2] http://webdirections.org