Transcript

Jen

This is the web ahead, a weekly conversation about changing technologies and the future of the web. I'm your host Jen Simmons, and this is episode 43, which is another episode in the web behind series with Eric Meyer. Hi Eric.

Eric

Hey Jen. Number five in our series, as a matter of fact.

Jen

Oh, nice.

Eric

Yeah! So...how have you been?

Jen

I've been good. Yeah, we just saw each other, less than 20 hours ago in San Francisco at An Event Apart, the conference that you run.

Eric

Yeah.

Jen

Where I was there, graciously asked to speak. It was a blast speaking.

Eric

Yeah, had a good time.

Jen

Really good audience. I love the audience for An Event Apart.

Eric

Yeah, it is very good. Hopefully some of them will have come over here to listen to us do this thing where we talk to people who are notable and prescient, or prescient and notable, hopefully, in the beginnings of the web, such as this week's guest, Chris Wilson. Hey Chris!

Chris

Hi!

Eric

[00:01:07] So, Chris has done a lot on the web for quite a while. In fact, he is one of the few people that I know who has been on the web longer than I have. And those are the people that I seek out, actually for this show a lot of the time. He's worked with a number of web browser code bases and worked for some of the biggest companies on the web, and we're really glad to have him here.

Chris

Thanks Eric.

Eric

We start really, each of these, Chris, by asking our guests how it was you first came into contact with the web and what you thought of it when you did?

Chris

Wow. Ok. Ummm, so I was an undergraduate student working at the National Center for Super Computing Applications, NCSA. I'm never going to say that whole name out again because I stumble over it every single time. NCSA built the NCSA PC Telnet software. They built a bunch of image visualization tools, all kinds of different stuff, and that's where Mosaic, the original web browser came up with Mark Andreessen and Eric Bina sort of came up with this idea. And I was working there after I graduated, and we decided, "Hey, this would be great to have on Windows, too" And we had a smaller Windows development team than the Mac development team, and the xWindows guys as well. So I took this codebase that we had and looked at it, realized it was really heavily designed to be running on xWindows or Mac, and we ended up using some of Tim Burners Lee's libw3, but mostly writing the entire thing from scratch, which was kind of exciting considering that it's me and one grad student who's a good friend of mine, writing all of the code and we weren't really experienced professional programmers at the time, of course.

Eric

Right, and so this is Mosaic for Windows, you're talking about.

Chris

This was Mosaic. Yeah, so this is Mosaic for Windows. We got a lot of code written, we had to rewrite a fair bit of it as well, of course. Over time. But it was interesting because at the time, the primary tools that you used for interacting with the internet were Telnet and FTP.

Eric

Right.

Chris

And educational contexts, Gopher was also somewhat of a big tool used, but really it was mostly Telnet and FTP. And FTP of course was easier to do anonymous connections with, or enable anonymous connections with. So it was a lot of FTP work. And I remember we spent an inordinate amount of time getting our FTP integration with Mosaic working really well. Which of course today you don't really go to a whole lot of FTP sites anymore.

Eric

Yeah. Do you know, do web browsers still support the FTP protocol? Do they not?

Chris

I believe they do, yes.

Eric

Yeah, so if you can find an FTP server.

Chris

There's still some out there. It actually the main benefit of FTP that FTP had for a while over HTTP and web servers was that it was stateful, so you did logins and you did changing directories and things like that, but of course when it got integrated into the web browser, we had to give this sort of stateless view of it, so behind the scenes we had to keep track of, "Well, you have a connection to this FTP server, let's go change directory to here and do a listing when you ask for that as a URL" and things like that. It was really kind of a messy translation between the two, but of course it's so much more common to just use HTTP servers now.

Eric

Right. Yeah, that's interesting that you had two completely different ways of accessing information jammed into the same tool, basically. You have the stateful, the FTP, and the stateless, HTTP, both of which were designed, right, specifically to be, respectfully, stateful and stateless. You had to try to support both.

Chris

Exactly. Yeah.

Eric

How much time did that consume?

Chris

Um, I don't actually remember the breakdown, but we spent a fair bit of time trying to get the FTP code working really seamlessly, but then as we saw the rise of the HTTP servers, which of course were much easier to write, much lighter weight, because they didn't have to maintain all these connections, the importance of FTP even by the time I left NCSA in '94, it was already kind of on the wane. There were more and more HTTP web servers out there and fewer FTP servers we had to worry about.

Eric

Right, yeah. So Mosaic started out as xWindows then.

Chris

Yeah.

Eric

And then you ported it to Windows. Because I think a lot of people, even me to some degree, even though I know some of this stuff, have this impression of Mosaic as like, springing fully formed form the forehead of Mark Andreessen and the NCSA team. It was there, right. It was on all the platforms all at once and then the world changed. But not so much.

Chris

It was really the idea came up when this guy named Dave Thompson at NCSA saw the work that Tim Burners Lee had done, and he showed it to Mark and Eric and a few other people and he was really busy with another project, so he didn't really get to focus on it, and Mark picked that up and said, "I'm gonna go build browser for that on xWindows, because it was NEXT based, what he and Sir Tim had originally done"

Eric

Right.

Chris

And he built xWindows Mosaic, xMosaic, and then the Macintosh team, which which was a bit bigger and more senior developers on it, said, "Hey, that'd be great, let's go put it on the Mac" And of course this was long before OS X, so it was a fairly complex and, even in Windows we were dealing with 16 bit Windows, so we had to do our own set of memory tricks.

Eric

Wow.

Chris

And this meant that we had pretty platform specific code for each one of these that we were writing. So when we finally managed to clear enough time, to finish off our other projects, enough to focus on it in Windows, which we started in, I wanna say it was April or May of '93, there was already xWindows was already out there in beta, the Mac browser I think wasn't quite out yet, in beta, but it came out fairly quickly, and then we built the Windows version, got our first release in late fall '93 I think, and it was immediately very, very popular. We'd had a lot of pressure building on us to get something out there on Windows, but we looked at porting the code, and it was just so much of the UI was xWindows based, or Mac based, and at that point, it was really hard to think of writing a full abstraction layer for all of that, that was not how we were used to building code. We basically just wrote it from the ground up using the transport libraries that we had, some of the parsing work that we had from Sir Tim's libw3, but the rest of it we kind of coded by hand.

Jen

[00:11:25] So I think for a lot of people, we tell this story to each other about Mosaic being the first web browser, but really there were several other before Mosaic, but then Mosaic was so awesome and kind of took over and took off, so can you talk about that? What were the other web browsers that were out first, and how was Mosaic different, and why was it that it took off so well, took off so much.

Chris

There were definitely a bunch of web browsers out at the time, most of them were not ones that most people remember very well. Certainly even before xMosaic was written, there was Sir Tim's browser, I obviously haven't had enough coffee this morning, I'm failing to remember what he called it, but there was also the Viola browser on xWindows, there were a couple others on xWindows that were early projects. But the core was really that Mosaic had an effort behind it. NCSA were part of the Software Tools group and our goal was to write tools that helped educational research and this was obviously one of those things that would help educational research and help the educational market and the research market. So we got to actually put people on it and keep going on it. And on Windows, even well before we had the first release of Windows Mosaic, even in alpha, there was a browser called Cello, but this, like several of the xWindows browsers, it was written by one guy, Tom Bruce I think was his name.

Eric

That's correct.

Chris

And at some point, he just kind of said, "Well, you know what, you guys are cranking away, you've done a whole bunch more than me, and it's not like I'm gonna catch up, so let's just go with it". But I think that a lot of it was just, we did a lot of work on it and it became very popular. Because NCSA was already a very big name because of PC Telnet. PC Telnet was the kind of standard browser, or standard Telnet package that most universities were using. Or there was an offshoot of it, another organization who took PC Telnet and added a bunch of features to it and a lot of organizations used that as well, but kind of the core was already the software of ours that they were used to using.

Eric

[00:13:52]
That's interesting to me that, as you say PC Telnet was so widely used and you had these tools that were so widely used, and yet you said the Mac team was bigger than the Windows team.

Chris

Yep.

Eric

Why is that?

Chris

You know, that's a really good question. I think at the time, Apple had a very very strong educational market presence, and even at the University of Illinois, we had a lot more Macs than you would presume based on overall OS market share at the time.

Eric

Right.

Chris

So I think that that sort of reflected on their choices and how they hired and staffed out the team and that sort of thing.

Eric

Yeah. It's just interesting because I was thinking, early 90s is not a time when you think of the mighty Apple, really.

Chris

No.

Eric

But I was at university at the same time and we had computer labs on campus that were all Macs. Like they were Mac SEs or whatever.

Chris

They were very direct in going after the educational market. They had a really strong educational pricing program, a strong presence with the universities then.

Eric

[00:15:08]
Yeah. So how big did the Windows Mosaic team get, or the overall Mosaic team. From what I gather it was you and one other guy when you ported it. Did it ever get bigger than that?

Chris

We shipped Windows Mosaic 1.0, I wanna say it was about then end of '93, and started working on version 2 shortly thereafter. And when we stared working on version two, we actually pulled in a couple other students to help do parts of it who did for a while, and then I left in April, I believe, of '94, and my friend that I was working with was named John Mittelhauser. And he was one of the guys who went off to Netscape as a founder there.

Eric

Ok. Basically the entire team left at that point, just about, right?

Chris

Pretty close. There were one or two people on the Mac project who didn't leave. There was a big flap about it because there was an in crowd who went off to Netscape. I'd already left a couple weeks before then to go to work for this company in Seattle, and everyone else kind of left and they made a big deal about "Oh, everyone left NCSA," and of course the few guys who were kind of like, "Excuse me, we're still working on NCSA Mosaic" but it was kind of a big deal for a while there.

Eric

Yeah, and then of course there was the naming deal, the naming problem.

Chris

Yes.

Eric

It wasn't Netscape originally.

Chris

No, it definitely was not Netscape originally, it was originally the Mosaic Communications Corporation, and then they started realizing that they couldn't really quite do that, and NCSA realized they had actually had never had any of us sign any kind of non-… not even non-compete, but like, any kind of confidentiality agreement, so they were kind of in a rough space then. And this was all new to NCSA, they were a research software group, they were not really designed to be… This is kind of why they gave the Mosaic license to Spyglass to handle, was because they didn’t really do licensing. The University at that point didn't really do licensing. The University of Illinois, really they had a lot of strong engineering colleges and everything, but they didn’t have the same kind of strong corporate licensing program that they'd been running for quite a while at Stanford, or some of the other universities like that.

Eric

Yeah, because back then, it wasn't as common, I think, for universities to do that. The fact that you could name a couple of universities that did it, like Stanford, back then. I mean, now, it's kind of expected, right, every university, every research university is always looking to spin something off and make a zillion dollars.

Chris

Exactly.

Eric

Not so much back then. It's interesting that Netscape was what sort of made NCSA, and mabye the University of Illinois realize that there was a boat there, and they were missing it.

Chris

[Inaudible 00:18:31 Sounds like "absolutely, they did" maybe?]

Eric

[00:18:32] Yeah. So you moved out to Seattle.

Chris

I did. I went to work for a company called Spry. They made a product called Internet in a Box, which you have to remember at the time, when you went and bought a Windows machine, you didn't have a network stack. You didn't have networking built into the computer. Even if you bought a modem, you didn't have a TCP/IP package, Windows didn't understand TCP/IP, the underlying protocol of the Internet, so you would have to go buy a TCP/IP stack, you'd have to buy a modem, and you'd have to pay a dialup service provider, and at that point, you were paying dollars per minute for some of the providers, too. It was very expensive. So Internet in a Box was one of the first attempts to take all of that stuff, put it in one box, on a shelf, you could walk into, believe it or not, an actual software store, because we had those back in the day. Buy this box, take it home, plug the floppy into the computer, type your credit card in, and you were online. And this was all new. You didn't type your credit card number into your computer then. There was no Amazon or anything. So you weren't used to that sort of thing. That was very new. But I went over to them, working on their version of the browser, because they licensed NCSA Mosaic, then moved out to Seattle a couple months later.

Jen

And when was this?

Chris

This was '94. I moved out at the end of June in 1994.

Eric

Mmm. And so Spry Internet in a Box. So there was a Spry Mosaic as well. That was part of the Internet in a Box, right?

Chris

Right. It was actually… we had like three different names for the efforts there. There was Internet in a Box, which was like, everything that we put together, their series was actually called Air, so it was like Air Mosaic and Air FTP, and that kind of thing. Although for a while they also called it "Spry Mosaic," and "Spry FTP". They did a rebranding there in the middle.

Eric

Ok. Yeah, I remember Spry Mosaic. I hadn't actually remembered Air. It's funny to look back now and think that you could buy a computer that would have no capability of getting on the internet from a software level, even if you had all the hardware.

Chris

This was a huge thing. Because, even if you had all the hardware, until Windows 95, you had to go buy a separate network package to get online.

Eric

Right, yeah. I worked for a university, Case Western Reserve University, from '92 to 2000, and I dimly recall that there was a period where we maintained campus license version. I don't think it was Internet in a Box, but it was something similar, like we had assembled a TCP/IP stack, one for Windows and one for Mac. We had floppies and there were techs who would go to professors computer and install it for them and that kind of thing. Yeah. There were people who were dedicated to that.

Chris

When I started at NCSA, the first project that I was working on was PC Telnet, and PC Telnet was a DOS program to begin with, we ended up porting it to Windows, but when I was working on PC Telnet, we did everything down to the network drivers. We had our own package of network drivers as a part of that install. I remember one issue I had to debug was the TCP fallback algorithm. When you send packets and you don't get any response, you're supposed to initially start trying again very quickly, but you're supposed to think about it and assume that you're probably clogging the pipe at some point, so you should back off and send them less frequently, and we had a bug with that that we had to fix. At the packet level. The TCP packet level. We were writing all this code and shipping it. Which nobody does this anymore because it's built into the underpinnings of the OSes.

Eric

Yeah. We actually had a variant TCP/IP stack called CWRU TCP/IP that… I wonder of that was based on that. Because as I understand it, part of the reason that they wrote their own is because we had a complete fiber optic network, so we didn't really have to worry about clogging pipes. So, there were some changes made. But that was a thing, right? Those were they days when differences in hardware installation could cause a university to hire somebody to change the TCP/IP stack to be customized for that particular site.

Chris

Exactly.

Eric

[00:23:27] Woohoo! It's interesting to me too, the fact that there was… like Jen was pointing out, we sort of thinking of Mosaic as being the first browser, but we also think of it as being one browser, and it was three, to start out with, right? It was xWindows, Mac, and Windows, and they were different code bases, it's not like it was just the same code base being produced on a different platform. And then, did more variants multiply out into the licensing space, or was it all basically the same three browsers, just rebranded?

Chris

What really happened was we built these three very separate code bases, I mean you tried to keep a lot of the same features, so when they added image support into xMosaic, we went and added it into the Windows version and the Mac version very quickly as well. Then when the bulk of us left and NCSA had to refactor and rejigger their team, they also [inaudible 00:24:35] to Spyglass. A separate company from Spry, by the way. Spyglass was a bunch of ex NCSA guys that were local, and they did have a lot more commercial experience by that point, so they got the master license to NCSA Mosaic, and then they would relicense it to all these other organizations, like Spry, for example, that wanted to license NCAS Mosaic code. And they actually took NCSA Mosaic and chopped it up, re-wrote it as a consistent code base that was cross-platform.

Eric

Mmmm.

Chris

I can tell, because this was what IE was based on. I could tell from the code, it looked very closely at my Windows version because the line formatting algorithm was exactly the same, and the structures, and things like that. But fundamentally, they repackaged all the code and kept one consistent code base after that. And most people started building on that. And they kind of slowed down development very quickly after that.

Eric

Yeah, one thing that I always remember about Mosaic is the appearance preferences. Because this was before… I mean Mosaic was not only pre-CSS, but pre font tag, right? And so, in the preferences, you could set any element to look like anything. You had to implement that, right?

Chris

I don't know if we ever implemented all of that. We did implement a lot of font controls where you could select the font for every element, certainly. I don't remember how in depth we got. It was one of those, we were just learning to use the Windows dialog editor, so we went a little overboard sometimes. And that was kind of a challenge later on, I think.

Eric

Yeah.

Chris

But we tried to offer a lot of options in there.

Eric

Yeah, what I remember, I was using a Macintosh at the time, but what I remember was you could set the font face, the font size, and the color of pretty much any given element. I shouldn't say any given element, I never went through and did a checklist to make sure absolutely every single element in HTML, but all the headings, and paragraphs, and lists, and stuff like that, so that you could do things like make H1s tiny and H6s huge. And crazy colors, and then you would undo all that after five minutes of surfing around the web because it would drive me crazy. But I look back at that as proto-user style sheets. Like, before stylesheets were a thing. And that was one of the things that I remember when Netscape came out and they got rid of that, right, and they were very clear, "We have all these options in Mosaic that aren't going to make it into Netscape because we foresee these browsers being used by people who are not computer nerds and who will not care. They will never go in there, and if they do go in there, they will just get confused. So there was a lot of simplification.

[00:28:02] But some of that, so far as I can tell, carried over into Internet Explorer as it got off the ground, which you were also part of.

Chris

Absolutely. Yes. Yeah, I think a lot of ideas from Mosaic had gotten carried over into Spyglass Mosaic, and then into Internet Explorer. Internet Explorer, it was interesting that IE 1.0 was really just Spyglass Mosaic with two features: rebranding, and the concept of internet shortcuts, which shortcuts in general, like symbolic links, were new to Windows 95, so they wanted to make sure those were in for internet sites as well. But I think that was the groundbreaking feature at the time, because otherwise you had to type in URLs or copy and paste in this text URL everywhere, which was kind of a pain.

Eric

So basically bookmarks, by another name.

Chris

Yes.

Eric

So that’s where that got started.

Chris

Keep in mind that even then, bookmarks were a link that was stored in a file somewhere. Like they were your personal ones, but how did you integrate that into your whole computing experience. Like, once you opened your browser, it was great to have these, but what do you put on your desktop to open up to go to your news site, or whatever else was out there at the time.

Eric

[00:29:18] Mhmm. Yeah. So you were part of the IE team, when did you shift over to that?

Chris

I lasted at Spry for about a year, a little bit over a year, and then I decided it was time to find a different company to work for. They actually had gotten bought by CompuServe, and they were shutting down all the software development part. Netscape was really, really outstripping them in terms of — I mean, I basically was the Mosaic team at Spry, so it was not really heavily invested in the software side, and CompuServe was not very interested in doing more of that. So, since I was already living in Seattle, I ended up going to work for Microsoft, I worked on a different project, basically a distant forerunner of Bing for a brief period of time, for three or four months. And then the Internet Explorer team, I was talking to one of their interns late one night and he realized that I had written a web browser before, which of course was not very common. [inaudible [00:30:28] day from one of their program managers, saying, "Hey, we'd like you to come work for us," which is really isn't a polite thing to do, go poaching other people and there was a big flap about it. I did not make a few people very happy. But it was clear I wanted to be working on browsers again. So I went over to the IE team right before we shipped IE 2.0. I did one check in in IE 2.0, I don't even remember what it was, it was some bug fix. And then I was set up so that when it was time to plan what we were going to do in IE 3, I was ready to go.

Eric

So what were some of the things that you wanted to add, like you're ready, let's start working on IE 3, and as you say you were set up to get things added, so what did you add?

Chris

IE 2 was really for the team, their big feature was adding HTML tables, the Mosaic guys, and then the Netscape guys had picked up on these tables thing, and they had already gotten that up and running, and the new features that Netscape had was framesets. So my manager came into my office while we were planning and said, "Hey, we'd really like you to do this framset stuff, it's really important." And I said, "You know, that looks great, we should totally do that, I absolutely totally agree, we have to do framesets, they're really cool, but there's this thing called stylesheets, there's this document, it wasn't a spec at the time, called Cascading Style Sheets, really cool, lets you control all these fonts, and you get to make really pretty looking pages, Netscape isn't even looking at this stuff. It'll be awesome, like, we'll totally do them one better." So he goes off, and he comes back half an hour later and says, "Ok, we got somebody else to do framesets. You should go do this stuff." So I went and implemented CSS for the first time in a major browser. So we got [inaudible 00:32:30] a really exciting things. Helped outdo the blink tag, I guess, give us some visual richness. But it was definitely a big feature in retrospect.

Eric

[00:32:41]
I always thought the big thing to outdo the blink tag was the marquee tag. Am I wrong?

Chris

You are not completely wrong. That was a much more direct attempt to out blink blink. It was kind of funny, I was looking into this a little while ago to look at the real history and the code blink tag came before IE2 shipped, and Lou Montulli who was at Netscape, he has a blog post out there that talks all about it. It was basically he and a bunch of other Netscape engineers went out drinking one night and he came up with this idea that, "Oh, we should come up with this tag that makes everything blink on and off," and then one of the other guys, and he doesn't name names, went back to the office and coded [inaudible 00:33:25] later that night, and checked it in. Then the IE team of course decided, "Hey, we've got to outdo this, let's come up with something that scrolls stuff back and fourth, and you can even control the speed at which it scrolls, and you can control whether it bounces, or just goes in one direction, you can even make it go vertical, instead of horizontal, all kinds of singing, dancing, really out blinking blink, like I said. And the scariest thing, the most depressing thing about this to me has always been, they were completely sober when they decided to do this. Designed it, and implemented it, and everything. This was not a we-were-out-drinking-one-night kinda thing.

Eric

Wow. And so it really was completely competitive, it wasn't, "This would be fun," it was, "Oh, they've got that thing, we need a thing. But a different thing."

Chris

I'm pretty sure part of it was just somebody thought, "Hey, it would be nice to have this really fancy visual thing." Because of course at the time, we didn't have this history that we have now of looking at what people will do with MySpace if you give them the ability to control everything, or what pages would have turned into like that. [inaudible 00:34:43] since though, that's not actually my fault. I didn't actually design or implement marquee. The first time I saw it, I was like, "Oh god, what are you doing?" but I do have my own set of issues, though.

Eric

Um, such as?

Chris

Well the number one, the one that I always own up to as being the worst thing that I ever inflicted was overlapping bold and italic tags, like the idea that parsing structure is not an absolute. I did this at NCSA in Windows Mosaic, for some reason I thought, "Hey, it would be great to be able to overlap these formatting tags, there's no reason not to, right? Because they just turn on and off formatting in a run of text, so I like hacked the heck out of the sanity that was our completely stack based parser. Then went and showed it to Eric Bina who is a relatively senior software developer, the guy working on the xWindows Mosaic, and he just gave me this look like, "What have you done? What are you thinking?" and in retrospect, I should have paid more attention to that.

Eric

Ah, well. The look served you well when marquee came up, right?

Chris

It did, yes.

Eric

That's interesting though, because that's a different way of looking at that same thing, rather than saying, "these are all elements and they form a tree," it's "these are toggles that switches this on and then switches this other thing switches it off".

Chris

Exactly. And it was kind of confusing at the time, because of course very few people were SGML experts, so very few people understood how that parser actually is intended to work, because there is some magic there. Like it is supposed to know, "Oh, you can end a tag, or you can have tags that may have end tags or may not." And you'll know whether there's supposed to be one inferred or not. And the parser that Sir Tim had come up with was not perfect about how it did that. It wasn't completely driven by the DTD, the document type definition of HTML, so there was some loose magic in there.

Jen

[00:39:05] Will you talk some about the culture of the team at IE and perhaps also in Netscape. It feels like when we look back at the browser wars from now, from a point at which most people believe that web standards are very important and working together, and having browsers work the same, it's really important. We sort of tell this story about the history, and how it didn't used to be like that, and back in the evil days, but what was it really like during that time? What was the thinking of the companies and the decisions that got made, how did they get made, where there any designers involved? What was that culture?

Chris

Well, one of the biggest things was that it was probably easy for most designers to tell was there really weren't designers involved in the very early days. Even the not quite so early days of web standards. I remember, it was a very, very long time until we had an actual designer sit full time on the CSS Working Group. Because it was hard to come up with the funding, the reason for being there, to put that much effort into it. And I think that when you look at the culture that we had inside the team, it was very competitive. I don't ever like the term "browser war" because it seems like, sort of scorched earth like, which I don't think anyone was quite that bad about it, but we were certainly trying to beat out the other guy, they were trying to beat out us, and we were looking for what we could do that was an advantage. And CSS is a good example of that. I jumped on CSS because I thought it would be really powerful and really cool, and give us some abilities that our competition didn't have, and we would have a richer platform then. It wasn't that I was just so intelligent and prescient that I understood that this would usher in this whole new world of separating presentation and content and give us this whole different system of thinking about how we put content together than we had prior to that.

Eric

[00:41:18] Yeah, well and I should say, in 1996, your presentation in Paris about CSS, you're on that panel.

Chris

Yes.

Eric

I was in the audience, that was the first time I encountered CSS was at that panel.

Chris

[Laughs] I was actually, I think, extremely sick when I was on that panel. I had caught a cold the night before. Right before then, I was supposed to actually have a presentation I think and I said, "Do I really have to do this?" to Burt, and he was like, "No, it'll be fine. Don't worry about it." So I got up and talked, and apparently I wasn't completely crazy or didn't completely lose it.

Jen

What was the presentation on? What were you talking about?

Chris

Interestingly enough I was actually talking about how we were solving this problem of having overlapping bold and italic tags, and how we could still do really CSS formatting in a world where we had this. Because we had to come up with something that could represent where that content lived in a strictly tree oriented structure. We had to have something that we would mirror back and be able to compare CSS selectors against at that point. So I actually talked about how we did that.

Eric

Well, the example carried the day, if nothing else.

Chris

Yeah.

Eric

Yeah, so one of these days I should dig back through my photo albums. Remember print photo albums, kids? Ask your parents if you don't. I have some from that conference. I have a blurry shot of that panel with you and Burt and a couple people I can't remember now. I should dig that up and scan it in. But anyway. So there was CSS being implemented. You had implemented it, at least to some degree, in IE3, and then of course Netscape scrambled to catch up.

Chris

Yeah.

Eric

[00:43:21] So, that was when we entered the very interesting period of two completely, almost completely incompatible CSS implementations. What was that like from your perspective as the person who was implementing it and then seeing that there were gaps, or bugs, or inconsistencies with your main competitor?

Chris

It was tough. It was kind of interesting in a frustrating way at the time because I felt like the implementation of CSS that I put into IE 3, it certainly had issues, a lot of those issues and the issues in IE 4 were actually because the spec wasn't there when we started coding, and there was this culture at Microsoft around compatibility that was, we had to fight against very hard to try to fix issues when they were just a standards issue. I actually was really proud of what I'd done in IE 3's CSS implementation, and what the team had done in IE 4's for CSS. And we were looking at… One of the things that not everyone remembers is that IE was absolutely groundbreaking in what it did with dynamic programmability, with the web as a very powerful and dynamic platform, where you could change things, edit things, change properties and attributes, and have things change in the live version. At the time, Netscape, their browser, for quite a long time, actually, I can't remember exactly when they started fixing this, but if you resized the window, they had to go reload the page. For a long time when I was at Spry, I remember that they would actually go reload the page from the network if you resized the window. And then after a while, they realized, "Oh, if you have form fields, you might have typed into form fields and then resized the window, we should cache those and then reload them," but they were still reloading the page. And then they finally [inaudible 00:45:24] dynamics in there, but for somebody new to the web, if you look at it today, you might wonder, you know you're digging through the document object model and it's like, "Why do we have a document.images collection? This doesn't really make any sense in the modern world to have a document.images collection." Like, it's not something that you're typically going to iterate through. You might want to collection of a specific set of images in there, but it turns out that's because that was one of the very few things that they could actually programmatically change from Javascript at the time. And even then, you couldn't change images to something that had a different width and height, it would still keep it as the same size because they couldn't dynamically re-layout. And we could dynamically re-layout in Mosaic and then in Internet Explorer as well.

And then in IE 4 we could start changing everything. We could start editing. Like I still remember between IE 3 and IE 4, we completely swapped out the rendering engine, and we had a completely separate team at Microsoft. They'd been working off on a forms package somewhere else for programmability, and they'd started looking at HTML, they'd adopted it, and they had all this editing stuff. And we'd never really heard of them before inside the IE team. There was like half a dozen of us who were working on the HTML and CSS rendering engine part. And [inaudible 00:46:47] I skipped a meeting where they were going to show off their code to us, but one of my co-workers went, and he was like, "We're screwed, we're out of a job. They already do pretty much everything we do, they have full editing already implemented, it's incredible what they can already do." And I was like, "Oh, ok, well that kinda sucks, but whatever, we'll keep working, we'll ship IE 3 and we'll be done." And they had me actually go over to this other team, the Trident team, what became the Trident team and demo the CSS stuff that I'd been working on to them. So I show it to them, and I show them like, "Here's the CSS spec, here's how it works, this is what it does, this is all the stuff I've implemented," showed these cool pretty examples, and then I said, "This is what I'm currently working on, this is what I hope to get in there before we ship," and I remember clearly somebody in this meeting saying, "Well, could you not?" Like, could you just stop, because anything that I implemented in IE 3 they had to be compatible with in IE 4 and they hadn't even started yet. So the great thing was when they swapped in this new team, I was one of only two people who were asked to move from the old team to the new team, because I was the CSS expert at that point and I got kind of an in there and got to reimplement it in IE 4.

Jen

[00:48:11]
So why was there a whole new team for IE 4, was it a new codebase? Did they start over with the codebase? Or what was the big difference between the two?

Chris

Yeah, basically they had completely started over with the underpinnings of the layout and content engine. So the parser was relatively straight forward. It was new, but it was pretty close to what had come before. The big difference was in the IE 3 engine, we didn't really know how to dynamically edit, it turns out editing is a very different task than just rendering text, just showing text on the screen. And you go about it a different way. You come up with different strategies to implement that sort of code. And they had started from this, "we're building a dynamic platform where almost anything can change dynamically, including what the content is." So we can go in, and you can click in the middle of an HTML document and start typing and it should be able to adjust to that and come up with a new rendering. Or you can dynamically animate property settings on font size and have it dynamically grow bigger and smaller. And this was not something we could have done before. We didn't have the language even internally to support that.

Eric

Wow.

Chris

That was really the huge part where we just did this complete leap frog over what Netscape had at the time, and one of the other things that we added in IE 4 was this notion of Positioning, which we had driven with the CSS Working Group to have a Positioning spec. But Netscape was still trying to constrain this problem, they had this competing layers proposal that was an actual tag, because then they could just worry about repositioning that layer, and not have anything change anywhere in the code.

Eric

[00:50:08] Yeah, layers. I remember layers. The layer tags. So, as you say, you drove CSS Positioning in conjunction with the Working Group, how closely did the vendors, and you in particular, work with the Working Group because at that point, because I think looking back, we sort of feel like there was the Working Group trying to say what CSS should be, and then there were Netscape and Microsoft who were galloping off too different horizons trying to differentiate themselves and ignoring the Working Group except when it suited them, but that doesn't sound like that's really what the deal was.

Chris

Well, I think with IE 3, we really did kick off the CSS Working Group. The CSS Working Group came from, there was another guy, a program manager at the time at Microsoft, Thomas Reardon, who he and I were working together on the CSS stuff, he was doing program management stuff around all of our platform, and we needed to consult regularly with Burt and Håkon about the spec. So we started setting up a weekly teleconference with them to chat about stuff, and then we added in Vidur Apparao who worked at Netscape because we wanted to get them involved, and then it very quickly turned into, "Hey, let's get this as a whole." Working Groups were just being started then in a way, so it was kind of a, "Ok, let's turn this into something more official and really push this, and turn this into a real spec," and that sort of thing.

But with IE 4, [00:51:54 inaudible] we actually did say as a company, "You know what, we're going to stop just randomly adding HTML tags." That didn't mean that we wouldn't ever add anything and propose it, but we would stop just ramming in tags, at least. There wouldn't be another marquee at the very least. And I think that that helped. There was still a lot of places where there were things added to CSS or to the DOM or things like that. It wasn't always, "Hey, let's go improve the spec first," and I think that's a big difference today. It's sort of like, most of the vendors mostly what we do certainly on the Chrome team is we say, "Well, let's come up with… let's try to figure out how we solve this problem space," and we get a bunch of people involved, and then, "Well maybe it looks like this, so let's propose a solution to it, and let's go implement it, but let's keep it in Canary builds, or under a flag, or some way so that it's experimental and we can still shut it down if it doesn't work out and go back to the drawing board an refactor things". Like for example, we just did this with Web Intents, where we gained some really great experience on this concept of providing intents and providing hooks into the user experience overall of the computer, but our implementation had some rough edges that we weren't happy with, so let's go back to the drawing board, come back, and figure out what the right thing to do is. And we pulled it out of our code.

Eric

Which, yeah, I can't even imagine anything being pulled from code in the '90s.

Chris

No, not really. It was not what we typically did. It was pretty challenging. And compatibility, like I said, was one of the hardest things, because once we had shipped this code, once we'd shipped doing things some way, even if we were violating the CSS box model completely, which it turns out we were in the end, we had to do something where we could maintain compatibility with the code that was out there. And that was where Tantek Çelik came up with the DOCTYPE, the quirksmode fix, to avoid that problem, at least, and I think that we're finally starting to see a lot more adherence to that kind of, "Let's focus on standards compatibility, not backwards compatibility as much."

Jen

[00:54:24] Well, and it sounds like there was originally a real drive to compete and to just sort of do whatever you wanted because you thought it was cool, because it was interesting, because it was working, and then slowly, I'm curious about this cultural shift to thinking about Working Groups, and thinking about putting things into a specification before implementing it. It sounds like in some ways it was a lot of learning the hard way, even on the part of the vendors, the browser makers, to say, "We got stuck with that forever because we didn't have an agreement with a group before we put it in." Do you feel like a lot of that came from worst case, learning as people went along?

Chris

Well, I think there are certainly some of that has come from experience and getting stung by that. I do think that if you look at the vendors, they're not all the same in how they go about doing that. Part of it is that they have different corporate cultures behind how they do things, and if you want to come out with something and say, "Look, we invented this brand new thing, and it's awesome, and it's all our idea." You can't really start by saying, "Hey, here's a problem space and we think this might be a good solution, what does everyone else think?" because you don't get to make a big marketing push around it then, and I think that for a long time that was the Microsoft culture. Let's get the biggest bang we can, and let's not really talk about what we're doing and what problems we're solving until we can throw out a beta release and show what great things we're solving. And I think they've started to get a bit away from that. But there's also the same challenges at other vendors as well. And of course when you don't have that, it can be very hard to tell what's official and what's really happening. You look at how Chrome does things, and I think it's a lot more chaotic to really nail down exactly when something becomes officially completely done, ready to go, unless it's a big effort. And of course the fact that the standardization cycle of the W3C, it's even hard to tell when the spec is completely done, makes that makes it even more challenging.

Eric

Well, if it were easy, anyone could do it, right? Yeah.

Chris

[inaudible 00:56:51] want anybody to do it.

Eric

[00:56:56] And so yeah, I remember how much of a struggle it was at certain points to get teams to come together. I do recall, though, it was very interesting, there was, I think it was the 7th International World Wide Web Conference, or maybe the 6th, the one in Santa Clara.

Chris

Yep.

Eric

On the IE team, like Scott Isaacs and number of other people were there, and so was the Netscape team. So yeah, it was the 6th International World Wide Web Conference, so it would have been in 1997, because they were one year behind in their years for a little bit there. What struck me about that, just as a gadfly or whatever, attendee wandering around the conference and being in the W3C track was the IE team, there were several of you, you guys were all over the floor, I don't remember if you were there personally or not, but the mantra, they would talk the ear off of anyone they could find about how standards were amazing, "standards, standards, standards," the next version of Internet Explorer was going to be standards compliant, and there was this big thing, "we're going to follow the spec," and "standards are the only way to go," and "one web," not that they used that phrase, and that kind of changed. The interesting part to me of course being that at that same conference, Netscape had several people there, all of whom appeared to have no real interest in standards, and then those roles reversed. So you were there for that whole period when the roles reversed. What was it like from the inside?

Chris

Well, I think from Internet Explorer's perspective, it wasn't so much a reversal, as we ran into a lot of challenges with how we implement that, given the culture that IE and Microsoft had, which was very backwards compatible. It was kind of a, "let's not muck up anything that we shipped, because people rely on this." I was talking about this at the Full Frontal conference last week, and one of the examples I used, was I remember in IE 5.0 or 5.5, I can't remember which, I remember investigating this bug that was the help files for Microsoft Cart Precision Racing, it was this Windows racing game that Microsoft came out with, I think they only did one release of it, and it was not a big seller or anything, but we were fixing code implementation in CSS that we had, and we broke their content, like it was overlapping text and images in the help files, so it looked horrendous, it actually did make it impossible to use, but that meant that if we fixed it, the content [inaudible 01:00:01] and thankfully I do remember with that one, we went ahead and did it anyways, but there were other issues where we can't really break how Word is spitting out HTML or something for everyone, and we can't go back and fix it up, either, so we got kind of stuck around issues like that. So I think that it wasn't so much that Microsoft or IE completely backed away from standards, than it was we started having a lot of challenges in how we actually deployed that sort of thing. And if you look at how that works when you're not as popular, I guess, it's a lot easier, frankly, to make changes then, and say, "Well, you know what, this is the right way to do it," particularly since people started around then, they were heavily using user agent strings and other tricks to say, "Oh, well if you're Netscape I'm going to do this, if you're Microsoft, I'm going to do this."

Eric

Huh, yeah you sort of get stuck in your own history, as it were. The decisions form an ever tightening net, in a way.

Chris

And when we —

Eric

So — sorry, go ahead.

Chris

When we started up the IE7 project, this was horrendously bad, of course, because it had been 5 years. People had gotten completely used to, "Well this is just the way IE works, it's always going to work this way, in effect. And they coded those assumptions into their web code. And time after time, I would go investigate some page, or IE 7 renders badly on this page, and I would go look at it, and it was basically expecting us to be broken like IE6, not to work properly. And we had to contact every one of those vendors, or those content authors, and say, "Hey, your code is broken, please stop expecting us to be broken, because that's now a broken assumption. And if you want to check for IE 6, and previous to do that, then that's great, but otherwise, please treat us like we know what we're doing." And it was a very tough role to take on.

Eric

[01:02:10] I can imagine. So you confessed to one of two errors that you made with the toggling b and i on and off, what was another one?

Chris

Oh jeez. We were talking about on earlier and I can't remember what it was now.

Eric

Uh, star HTML, actually.

Chris

Star HTML, right. So for those of you who don't know what star HTML was, it was actually a workaround in CSS to determine are you running in Internet Explorer, effectively. Like you could do stuff that would only affect IE without actually saying, "IE do this." And the reason that this was in here was because we had inside the rendering system from IE 4 onward, we had a root node at the top of the tree, the rendering tree, that was invisible, like you couldn't go troll through the DOM and look for it, it wasn't there, the HTML was the top of the tree, but we did CSS selector magic, we actually looked at the entire tree, including the root node, so if you said, I want this to match HTML inside any element, well every browser out there HTML was always at the top, like it was always the root of the entire tree, except in IE, we had this magic nameless root node that would match a star selector and have it apply to anything in there. And I remember the instant I first saw this, I thought "Oh, yeah, I know what's causing that," like I wrote the selector matching code, I knew what was going on immediately. And it was always interesting what was happening and why without even looking at the code by there.

Eric

So, I guess, my question is, why was there a magic root node, what was the reason, like what was the necessity of having that.

Chris

I believe that… so that was actually in there before I started on the team, I believe it was actually due to the rendering and management of layout for the entire document. They had to hook it on somewhere, so they just put in this root node as a place to store it.

Eric

Hmmmm, interesting. Yeah, ‘cause there was a lot of speculation at the time that actually what it was finding was the DOCTYPE element, which is not actually an element, but there were people who said, "Oh well Explorer thinks that the DOCTYPE, that you opened an element and the HTML element is inside of it, but that's not actually true.

Chris

Nope, we actually did not even parse DOCTYPE. I believe it got stored as like, we had some like, "This looks kind of like a comment to us" sort of node, and that's what DOCTYPEs were getting dumped in as, until we started using the quirks mode fix, which wasn't until IE 6 or 7, I actually don't remember anymore.

Eric

Um, 6.

Chris

Was it 6? Ok.

Eric

Yeah, 6 is where you started —

Chris

Bloat

Eric

[01:05:26] It was one of the reasons that 6 was able to hang on for five years, basically. So then I guess I have to follow up: If it wasn't matching the DOCTYPE with star HTML, then what was being matched with the star plus html hack, which actually worked in IE 7 and later.

Chris

Star plus, I believe actually was matching the DOCTYPE node. Because then, by then we were actually parsing it and storing it as a node. We needed to remember what the DOCTYPE was, because we started using it a little more consistently. And it had that same magic root node, like it had something hanging off of it. In fact, [inaudible 01:06:09] why we had a root node was because html in theory is the root of everything in the tree, but in practice you could have a document where you said html and had an entire html tag and all of its contents, and then you stuck some other tag down in the bottom, and we had to parse that, remember it, and be able to reconstruct it. So we [inaudible 01:06:35] as a container for everything.

Eric

Ah, so if someone put a script after the </html>, then you needed to still store it.

Chris

Exactly. It needed to get stuck in a tree somewhere, and obviously it wasn't part of the html, since that had closed.

Eric

[01:06:51] Huh. Very interesting. See, I learned something here. That's good. I like that. Well, we could probably do this all day long, but I think this is a good place to stop, because it sort of got us up to a certain pause I think in browser development. I think we should do this again at some point and talk about events after the point where we're stopping here. But I'd like to thank you very much Chris, for being on the show. This has been fantastic.

Chris

Thank you for having me. It's been great!

Jen

And I should thank our sponsors the CSS Dev Conference, the In Control Conference, and Shutterstock for sponsoring the show and making it possible. Chris, where can people follow you on Twitter, or other such feeds, if they want to.

Chris

So the easiest way to follow me is to just look for @cwilso, C-W-I-L-S-O, no N, that's my name on Twitter, I have cwilso.com, I have cwilso@google and gmail, and pretty much everywhere else. And of course just +ChrisWilson on Google+. Twitter and Google+ are where most of my rambling actually goes, so it's easiest just to look for me there.

Jen

Nice, and people can follow Eric @meyerweb on Twitter, or meyerweb.com is your website, right?

Eric

Correct.

Jen

And I'm @jensimmons on Twitter, and you can also follow the show, @thewebahead, on Twitter, where we occasionally send out notes about announcements about shows coming up and such. So that's it. Thank you to everybody for listening and we'll be back next week.