Stephanie Troeth: The Microsoft proposal for browser version targeting in Internet Explorer 8 to default to IE7 behavior for all current DOCTYPEs has divided the web developer community. What implications would this have for web standards adoption? Would the web be in a state of damage if IE8 defaulted to standards mode? Some members of the Web Standards Project got together on a Saturday afternoon to discuss their concerns and possible solutions with Chris Wilson, the Platform Architect for IE8.
Aaron Gustafson: This is Aaron Gustafson and I'm on the Microsoft Task Force on the Web Standards Project.
Chris Wilson: And I'm Chris Wilson, I'm the Platform Architect on the IE team and also on the WaSP Microsoft Task Force.
Faruk Ates: I'm Faruk Ates. I'm a Web Standards Project Member.
Porter Glendinning: And I'm Porter Glendinning. Just this month I’ve started a new job with MRIS, the largest real estate multiple listing service in the U.S. I've been a Web Standards Project member for, gosh, forever.
When we had our initial discussions on this, I think, I was where a lot of the community was. Sort of feeling a bit surprised with this idea and the initial gut reaction to it is, “This doesn't feel right.” I think that a lot of the community and I, myself, have distilled this down to the thing that doesn't feel right is the default behavior. That for me, I wonder, well, so, this is fine for now. This is fine for building sites for IE7 and transitioning them to IE8. But what happens at the next major release?
Faruk Ates: The core of it is that we are hoping to provide options that will allow Microsoft to choose, or have IE8 use the standards behavior by default without a significant risk of breaking any web sites.
Chris Wilson: I think that the way that we got to the idea that we needed some method of version targeting really was because of the experience that we had in IE7. Where...when I came back to the IE team to work on IE7, I carried with me, of course, a lot of context from IE6 and IE5.5 and all the previous releases that I had been a part of. Back in the IE5, 5.5 days, and all the way up through there actually, we had this very strong focus on compatibility.
The unfortunate side of that was that basically meant that we wouldn't change anything because of compatibility. Right. We would presume that people would already be building on the things that we did. It really was pretty appropriate at the time. They depended on the behavior that we had.
When we did IE6, on the other hand, we actually looked at the DOCTYPE switch that Tantek had first put in Mac IE5. And we said, “Well, this will do it.” Right. We can use this as a way of switching on standards compliant behavior. And, you know, we won't break compatibility with the stuff that is out there. So, that's great. But, we won't have to follow all the wackiness that we did before under standards mode. That helped us tremendously in IE6 because we could do the box model change that we did, and there were one or two other things I think that we did in IE6 to be more standards compliant. And we'd really been looking forward to doing a lot more on that with the next version of IE.
Then, you know, there was kind of a long pause between releases. The unfortunate thing then is, that between the time that we released IE6 and the time that we released IE7, the adoption of standards mode on the main part of the web grew tremendously.
When we started, sorry, when we shipped IE6, shortly thereafter, I did a project internally where that part of what we did, for side reasons, was we looked at how adopted the standards mode DOCTYPE was and I think in the top 200 US web sites, there was exactly one site that said, “we are in standards mode.” Everyone else was in quirks. But, by the time we shipped IE7, approximately half of the top 200 US web sites were in standards mode.
So, I spent a long time, as we were shipping IE7, and afterwards, having to go follow up on problems that we were having. Not even just on the major sites, you know, not just ESPN.com kind of sites, but all of the people who had, you know, who would written scathing blog posts about how bad our standards support was. Then I'd dig into their problem and realize that it was really, we had changed behavior on them and they had just expected that it was because we were poor at doing standards support.
In many cases, if they had actually given us the content that they had offered to the other browsers, we probably would have done a better job at rendering it, at that point.
But the problem is, effectively, that, we get given this content that is carefully tweaked to look good in whatever the last release of IE was, or whatever some past release of IE was. So that lead us to this place where, you realized that we really had to figure out some way of getting something like the DOCTYPE switch, from our perspective, of we knew that it wasn't going to effect a ton of current content.
Aaron Gustafson: I went through a lot of the emotions that pretty much the entire community has gone through since Chris and I began discussing this, what was that, almost a year ago now, Chris? Something like that?
Chris Wilson: About, yeah.
Aaron Gustafson: It certainly seems like it. It kind of came out of our discussion when Microsoft first approached WaSP and the JavaScript Ninjas about what did we want to see in terms of JavaScript improvements in the next version of IE, which at that point was still code named IE.next.
We had had some discussions about that, and one of the things that we realized was, and recognized early on, was that, there were going to be some points that were going to essentially break compatibility with previous versions of IE, as IE was improved and brought into better alignment with the standards.
One example is document.getElementById which has been collecting by the name attribute as well, which isn't what it should be doing. But any site that employs that, if they don't know that they should be actually using the id attribute instead of the name attribute, their stuff is going to break.
To me, I guess one of the things that I see in the argument that is going on right now about the default behavior is that I feel it is so focused on CSS. Which, yes, a layout breaks; it can be detrimental, in most cases, not so horrible. It may not look quite right, or something may be out of alignment, or something like that. I don't consider that critical.
On the other hand, with IE8’s improvements and changes and such in JavaScript, there is the possibility that entire sites may fail to function if the default behavior was what was opted in to. Because so many sites, against all of the best practices and better judgment of people who are out there touting unobtrusive JavaScript like I have been for the last couple of years.
There are so many bad scripts out there and there are so many bad script aggregation sites that have basically helped people who don't want to learn JavaScript to quickly add things to their pages and that is the entirety of their functionality. You know, everything requires JavaScript, basically. And if you were to come along and all of a sudden not support what they are using in JavaScript, that is going to break those sites. I don't care so much about the developers themselves, they should be writing better JavaScript, but I do care about the people who have to use their sites to get their day-to-day work done.
Porter Glendinning: But I think there is an important difference, at this point, Aaron. That the default behavior issue now is yes, breakage could be catastrophically major.
Aaron Gustafson: Yeah
Porter Glendinning: There is no question. Certainly, when we start talking about DOM changes, there are going to be sites that will break horribly if they are forced into IE8 standards mode.
Aaron Gustafson: Right
Porter Glendinning: The issue that differentiates this upgrade from the last one, for me anyway is, is there is an easy fix this time. If I have a site that I don't want to go and debug all of my DOM problems and all of my CSS problems, I can throw in this new header or this new meta tag and I can say, hey, drop me back to IE7 mode.
Back when the last upgrade happened, there was not that option. It was, go in and fix all your bugs was the option. And there was no other choice. So people spent a lot of time and a lot of money upgrading sites to work with IE7. And that is different now. They can go back in and add a simple meta tag or a simple header that then their site will continue to work the way it always worked.
And for me, I feel like, if that is too much effort than your site is effectively abandonware. Are we going let abandonware dictate where the web is going for the next ten years?
Aaron Gustafson: I do see that point. And I understand it. I think the one thing that I have a problem with is unfortunately most of those people don't read. They may continue churning out sites, but they are not upgrading their skills. They are doing a disservice to their clients, of course by doing that, but, their clients, in many cases, may not know better.
I see tons of web shops here in Connecticut that are not producing good quality stuff and would not do the reading to understand that this is what they have to do in order to get their sites to work. So their clients are going to continue getting screwed because they are not aware of this.
Faruk Ates: Three ideas I wanna list: First is Chris Kaminski's idea of making Microsoft IIS systems – the next release – add a patch which simply adds the HTTP header to put IE8 in compatibility mode, and so all systems running on IIS would — as of the next patch — be prepared for compatibility mode just as an initial means to alleviate those problems for millions of intranets and websites.
Chris Wilson: Challenging part there is that I don't think we want a system that ... I don't think actually anybody really wants a system that's going to work differently by default with Microsoft servers and Microsoft clients. We really want the communication between the server and the client to not really matter so much; or I should say, which server you're hitting — which type of server — shouldn't matter. The challenge with that would be if they develop their content not being served to an IIS server, then deploy it to an IIS server, suddenly it works differently by default. I think that might be a little wacky for people to get a hold of.
We did actually want to make sure and this is why we ended up ... one of the reasons why we ended up with, the meta tag. We did want to make sure that people could, in fact, opt in entire servers to upgrade the entire server to something different.
Faruk Ates: The second idea is Steve Ganz's idea which is to start offering IE8 as a beta with the default being the standards mode and then see what the reception from the community is like to that and how much, if any, damage there is.
Chris Wilson: One of the things that you'd be able to do when we do offer the beta for IE8 is tell it you want to be in standards mode, and tell it, "hey I just want to see what the world looks like when I'm running in standards mode." The thing that we saw with IE7 was three-fold I guess. When people hit issues, they didn't really know whether it was just a bug in the beta or not, and they tended to presumed that it was. In fact, a lot of people, a lot of the major sites — you know, like, the, sort-of banking, high-end delivery sites — they didn't even want to touch it until we were done, until we were shipping RTM. Then they would pick it up and come up with a test path, and test it and everything else. Some of them were extremely ... I'm not sure what the word I'm looking for here is ... but they were really certain that that was the right thing for them to do. And I can kind of understand that, because they don't want to have to keep fixing it as they go.
But the second problem that we saw was that the presumption, a lot of times, was that we just gotten something wrong. Not necessarily that it was a bug in the beta and that we'd just done something else goofy and we'd just made standards support worse, or something like that. That leads us to the third problem, because it didn't scale very well for us because we had thousands and thousands of websites that we got reported, and we had to go try to figure out what was broken with all of them. Figuring out what was broken with a lot of them, granted it is better now that we have this version targeting mode that we can flip back to a previous version, but it is sort of knowledge intensive thing to do and I ended up having to do this a lot of time personally because of that – because it did require somebody who was pretty knowledgeable about how the things fits together.
Faruk Ates: Third idea is to make IE8 standalone, which means it can be installed right next to IE7 or IE6, whichever version is installed on the system; or at least the beta be standalone, so that it can be installed and uninstalled without any significant hassles or whatsoever.
Chris Wilson: Sure, we can with IE8 you can tell it go into standards more, we've been looking at several things that allow people to, directly, in some part of the UI at least, toggle into standards mode, do sort of similar to what Opera does, tell it to toggle back into IE7 UA string and that sort of thing.
Faruk Ates: Similar to Opera, just a button in the interface that's there by default or would this be a little bit more hidden, like as a preference to be enabled, or ...
Chris Wilson: Slightly more hidden than a button in the toolbar, but not as hidden as, say, the Opera site preferences.
Aaron Gustafson: Would it be less hidden than, like the, to say turn on and off Javascript debugging, or would it be probably on par with that?
Chris Wilson: That's a good question. Which ... are you considering javascript debugging to be the thing that's buried in advanced user options, or actually getting it to work which requires some [...]?
[All laugh]
Cos actually the answer to either one, would be that it would be easier to get to than that.
Faruk Ates: So Chris, the way I would envision that from how you describe it now — it's like easier than this but not quite a button in the toolbar — is if the user goes into "Tools > Internet Options", it's like the first screen, the setting on that general tab?
Chris Wilson: Yup.
Faruk Ates: Okay, something like that.
Chris Wilson: I'm mean, that's not actually what we're doing, but it's that level of ability to get to.
Aaron Gustafson: Of ease. Yeah.
Faruk Ates: Yup.
Chris Wilson: The challenge with this though and this ties in with the idea of making IE8 standalone. The real challenge for us is that, at the end of the day, we are intensely user focus in how we go about building our system. The other challenge is that our users are not typically the computer-savvy, internet-savvy type of person. They are not the sort of people who are web developers, right? They are ... I mean I use this example all the time but it's actually the way that I think about it our user base: it's my mom.
So, my mom is not a computer idiot — she's really isn't — like she was been writing punch card programs before I was born, but she doesn't step up to her computer and say, "Oh, my financial site is broken, what do I do to go fix that?" She calls me on the phone and asks me why her financial site is broken, or she calls them on the phone and ask them why it's broken.
The challenge that we had with thinking about doing a side-by-side that users could actually use: it's one thing to say it's a great thing for web developers and for testing to be able to run side-by-side and do that multiple-versions-on-one-machine trick, it's another thing entirely to say that my mom is going to able to keep in mind when she needs to be running IE6 or IE7 and when she can run IE8. And, that also means that any benefits that we do put into IE8, that affect everything — like performance — she won't get, in that case.
Faruk Ates: Regarding that standalone, I see your point. But what about having the beta be available as standalone?
Chris Wilson: I think the beta, in order to get the behavior of IE7, is actually pretty straightforward. Getting the beta to just give you IE7 behavior because of the way we built our new layout engine, and the way we've done the opt-in, and our ability to toggle that opt-in, I'm not particularly worried about getting IE7 behavior. Actually the most concerning thing for me right now is the UA string that we send, just because we'll upgrade the UA string, a lot of people are not prepared for that, right — just for us to go from saying "IE7" to saying "IE8" in the UA string will cause a bunch of sites to say "oh we don't know what you are, go away".
Faruk Ates: On a similar note, you have the UA string, but you also have conditional comments. Jina Bolton asked you about: when IE8 is in compatibility mode, and we have a conditional comment for IE7 and a conditional comment for IE8, how is it going to handle that situation?
Chris Wilson: That's a great question. It's actually one we've been wrestling with over the last couple of months. The version vector plan right now, have the version vector and the UA string reflect the real version of IE8 and see what compatibility that turn out to be. I mean, it's unfortunate but the user-agent string is always the biggest compatibility challenge.
Porter Glendinning: Are we at a point to look towards the future? When 8.5 or 9 that comes out that has further significant changes to bring it in line with whatever else is new. What would we even imagine that the default behavior would be then? We'd be doing IE7 as the default possibly up to 8 and 9 as the future upgrades that people could step up to? Where does this go, after this upgrade, is my biggest question, I think. For me, it seems like shifting the pain point from today to tomorrow.
Aaron Gustafson: Can I jump in here for a second? I mean, one of the things that we haven't really talked about yet is the default opt-in of future DOCTYPEs. With IE8 coming out, sensibly HTML5 will be auto-opted into IE8 standards mode, not into compatibility mode. So as we use future DOCTYPEs or unrecognized DOCTYPEs — so ones that haven't existed in the past or custom DOCTYPEs etc., IE would just jump to IE8 mode or IE9 mode, whatever it is, as long as that browser hasn't determined that it's in enough use to warrant locking it a particular browser version or targeting it to a particular browser version. So if we were to start using HTML5, which obviously isn't out yet, and probably will not be a finished spec for a while. But once that comes out, we'll be able to be using those features right away as soon as the browser actually implements them. But we're not going to be held back from doing that. We can start opting in to that stuff automatically by DOCTYPE and not have to have the meta or the header to say, "this is the version that we want to auto-opt in to."
Faruk Ates: So my concern is that, it basically puts the whole burden on HTML5 or forces people to switch to HTML5 — but what if you don't want to use HTML5? A lot of people still have many issues with the way HTML5 is put together. Because we've discussed earlier that with XHTML 1.0 Strict, we don't know how many sites there are that use the strict DOCTYPE for XHTML 1.0 and are actually broken in that they rely on non-standards compliant behavior in IE6 or 7 to work despite having an XHTML 1.0 strict DOCTYPE.
Aaron Gustafson: Do you think that it might be possible or it might be worth exploring whether using a strict mode DOCTYPE as opposed to a Transitional or a Frameset mode DOCTYPE that tends to be what tools are pushing by default when they are auto-injecting this stuff into a document, such as Dreamweaver or the like, content management systems, etc. Do you think it's worth exploring whether strict mode, or strict DOCTYPEs have enough penetration to warrant them being auto-opted in for IE7 as opposed to potentially IE8 rendering mode?
Chris Wilson: We can look at the numbers and see what the effect of that would be, and it's possible if other people think that that would be a benefit. I don't recall having looked at those numbers explicitly, like what the breakdown is between XHTML 1.0 Strict vs Transitional vs HTML4. And of course, there's whether it has the URL after it or not. I'm not sure that ends up being a more or less explainable message to web developers or whether it's a better or worse in that sense.
Faruk Ates: I think it's a very worthwhile thing to investigate.
Aaron Gustafson: I think it would be too.
Chris Wilson: Well, I think,as for the decisions about ... when the decisions will be set in stone ... they are set in stone sometime shortly before we ship our final version. I think that we haven't seen anything that would protect our user experience as well as what we've come up with, but we're certainly trying to reduce the pain on web developers. And we really do want to encourage people to be building content that is interoperable and follows the standards rather than picking some arbitrary version of IE, and just coding for that. At the same time we have to recognize that the web as it is today, by and large, people do test against various browsers and make sure that they work on there, because at the end they are user-focused as well.
Stephanie Troeth: You have just been listening to an IE8 Round Table Discussion between members of the Web Standards Project and Chris Wilson, the platform architect for Internet Explorer 8. We would like to thank Chris, of course, Porter Glendinning, Faruk Ates, and Aaron Gustafson, for having taken some time out kindly to speak on this topic. Technical production for this podcast was by Glenda Sims and Stephanie Troeth. Thank you for listening.