This is a transcript of What's Up With That Episode 11, a 2024 video discussion between Sharon (yangsharon@chromium.org) and Chris (cwilso@google.com).
The transcript was automatically generated by speech-to-text software. It may contain minor errors.
We've heard about the web platform, so what about web standards? How have they evolved, and what does the process look like now? Today’s special guest is Chris, who has worked all across the standards space, as is Google’s W3C AC representative.
Notes:
Links:
00:00 SHARON: Hi, everyone, and welcome to "What's Up With That," the series that demystifies all things Chrome. I'm your host, Sharon, and today, we're talking about web standards. What is a web standard? Why do we need them? How do they work? Today's guest telling us all about them is Chris. He's been working on standards in various capacities for 31 years, and is Google's W3CAC representative and sits on the W3C Advisory Board. Welcome, Chris.
00:24 CHRIS: Thanks.
00:24 SHARON: Thanks for being here. So question number one, what is a web standard?
00:29 CHRIS: So web standards are really something that we got used to doing to codify how to make interoperability happen on the web. Even very early on, there were more-- there was more than one browser, and they had to work in roughly the same way. And for a very long time, we sketched these out more than really, really got into the details of how to make sure they interoperated well. This created a lot of problems for several decades, actually, that had to be reverse-engineered, exactly how does Internet Explorer implement this one piece, things like that. And the place that we finally got to is what I would consider a web standard where the real goal of having a web standard is simply to make sure that you can have interoperability in the open web. That you're not reliant on one set of code to do something.
01:14 SHARON: OK. Yeah, lots of stuff in there that we will get into in more detail. Can you first tell us what some of these letters that I just rattled off? What does the W3C--
01:25 CHRIS: So--
01:25 SHARON: Air conditioning?
01:25 CHRIS: Yep, yep, yep. The W3C is probably the largest Standards Developing Organization, or SDO, for web standards. It started out as the place for HTML and the DOM and all kinds of other pieces of the web and where they came together. CSS is still managed there. So all stylesheet things and stuff like that get defined inside a working group in the W3C. The AC is the advisory committee. This is really just-- I'm Google's point of contact for the W3C. We pay membership dues. We get to vote on things. I'm the one who places the vote. This sounds really powerful and great. It's not, really. It's more a, I have to run a regular meeting, ask a whole bunch of other people questions like, hey, how do you think we should vote on this? And then figure it out and place the vote. The Advisory Board, on the other hand, is an elected position where I have to go out to the entire W3C membership, all the other companies, and run for election every couple of years. I've sat on the advisory board for, oh, off and on about a decade now, I think. And it is, however, just advisory. It's kind of we tell the W3C what we think they should focus on, what interesting technical areas they should get into. Maybe you should pay attention to AI or things like that. But also things like, at their meetings, what kind of health restrictions there should be because of COVID or things like that. So all-across-the board details.
02:59 SHARON: OK. Yeah, I saw on the Wikipedia page that the W3C has 400-something-odd members. So are those typically all companies? Or what are the other--
03:11 CHRIS: It's a broad mix. There are a lot of really large companies. I mean, the ones you would think of, you know, Google, Microsoft, Amazon, IBM, Apple, Mozilla, like loads and loads of big names. There are a lot of smaller companies as well. There are a lot of academic institutions. There are a fair number of invited experts in various places, too. So single people who have a specific interest and they get invited to contribute that interest. So they're not even technically a member, they don't have to pay their dues or anything, but they feed into the whole. A lot of the work-- most of the work, really, in W3C is sort of public, or at least semi-public. And you can participate in it without actually even joining for some areas. The biggest challenge for web standards, too, when I mentioned earlier, interoperability being key, another key is making sure that you're collecting the intellectual property rights to implement thing, too. So people can't sue you for implementing cascading style sheets, for example. And there's a whole set of complexity there. Most of us don't really care about that or don't want to have to care about it. I sit at the intersection where I spend a bunch of time with our patent team and other people's patent teams as well to make sure that we're signing off on everything, dotting the I's, crossing the T's, that kind of stuff. So they are truly free to implement.
04:40 SHARON: Mm-hmm. It sounds like the kind of stuff you do is a lot of wrangling people, running meetings--
04:46 CHRIS: Absolutely.
04:46 SHARON: Which is typical. As you stay in any field longer-- area longer, you become an expert, you end up doing less of the stuff that is why you got into it and running meetings. So in the standards phase, what is the, if I had no meetings to run, this is what I would enjoy doing?
04:59 CHRIS: Oh. Hmm. I'm not sure what the current one would be. So a number of years ago, probably starting about 10 years ago, I actually did exactly this, which was I had been doing a lot of higher-level standard stuff. By that point, I think I was already getting onto the Advisory Board and that driving the overall objectives. But I got super interested in audio. And I spent a whole bunch of time in the Web Audio Working Group at the W3C working together to come up with these really, really powerful audio APIs that could do amazing stuff. I'm a synthesizer geek in my spare time. And being able to do a ton of those things just in a browser in JavaScript really easily was super fascinating. Wrote a ton of sample code, a ton of applications that would let you play around with various parts of this. I'm a horrible UI designer, so I didn't really release any of this as an application, per se, but like I built a vocoder completely in a web page, which was pretty awesome.
06:13 SHARON: OK, OK. Very cool. Yeah, because a lot of people you see, they're like, oh, I'd would love to be doing this, but instead I am coordinating people somewhere.
06:20 CHRIS: There are always some parts of that, but I try to mix it up a little bit. And every once in a while, I'll try to go deeper in a technical topic, so I don't completely lose that.
06:26 SHARON: Makes sense. In our last episode, we had Rick on to talk about the web platform, so a bit more general. And one thing that came up was specs versus standards. So can we hear your take on what the difference between these two is?
06:37 CHRIS: So standards are specs. Specification just means you wrote something down. And there's this progression from an idea to an actual accepted interoperable standard. And specs is the whole journey that's a specification. When you start out, you usually do something like-- we have this pattern called writing explainers. And it's basically write down what it is you're trying to do. Like what the use cases are, what the scenarios you're trying to address are. And even maybe a sketch of what a solution to that problem might be. And then you keep refining it. And you keep working with other people, you publish that, you get a bunch of people together as a community to work on that idea. And then you start saying, OK, here's an actual solution to it. Here's the idea for what the solution looks like in JavaScript, or the set of elements that you're going to have or CSS attributes that you're going to have, and exactly how they're going to interoperate. And when you get to starting to really write a standard, you have to write the real specification, which is algorithmic steps of how an implementation would deal with these. And then you have to work together. Write documentation for it. Make sure that people understand how to use it as well as implement it. So specification is a more general term. Standard is really what you're working to release at the end, because then if another browser came along and said, hey, I want to support this wacky new feature you created, they have a manual for how to do it. That's the standard.
08:18 SHARON: OK. Well, OK. Well, I have some other questions about that, but I think it makes more sense to start with Chrome, which is what we're probably all here to talk about.
08:24 CHRIS: Yes.
08:24 SHARON: Which-- so some of the stuff you mentioned-- the DOM, CSS, whatever, that all, easily you assume, is implemented somewhere in Chrome.
08:37 CHRIS: Mm-hmm.
08:37 SHARON: Is there any kind of pattern or system to where things in Chrome are implemented? And if you're just looking at the code in Chrome, can you tell if it's implementing a standard or if it's just Chrome general code?
08:57 CHRIS: It's really hard to answer that question, but I will say, most of what we do in the web standard space is-- sorry, in the web platform, space is hopefully adhering to a specification somewhere. It may not be a standard yet because we don't-- like, we don't get everything to a fully accepted standard, W3C-stamped recommendation before we ship it, necessarily, but there should be a spec. If there's no specification, you probably shouldn't be writing code that does something that isn't specified anywhere. And at the same time, mistakes were made. We do get there eventually, but we have gotten really good at this. And so anything that's in the web platform space typically has a specification. Where it is in the process to getting to an interoperable standard, getting other implementations to sign off on it and ship it, that's a big variable. And some things don't get there. Some things-- Chrome is the only browser that ships it, but we still should have a spec somewhere that says that. And it should be somewhere in the standards process, whether it's still an incubation. People haven't accepted that, yes, we need to do this in a working group. We need to make a real standard. But hopefully, it's getting there.
10:18 SHARON: OK. So it sounds like, with what you mentioned of the W3C, there's all these different sections of it that are responsible for different things. Audio, CSS, other stuff. What other organizations besides the W3C have specs and standards that Chrome implements?
10:39 CHRIS: Loads of them. Biggest ones-- and some of these are super important. So the WHATWG is a huge one. WHATWG is really-- about two decades ago, this basically forked off from the W3C because W3C started focusing only on semantic content and not the web as an application platform. And a number of the browser vendors at the time were like, wait a second, everyone's using it as an application platform. They want to understand what things are going to render. They want to make sure that all the browsers use the same interpretation of what the HTML spec says. So they took over HTML and the DOM. It's pretty much entirely run in WHATWG. And it is heavily around interoperability. Like, that is the primary goal of all the specs at WHATWG. There are other specifications that happen there, too. Largely around things like fetch. Things that are sort of base-level platform functionality. At W3C, there's a broad array of different things. There's stylesheets, as I mentioned earlier. There are a lot of different APIs and things. The baseline of protocols, though-- like HTTP is a great example. Things that happen at the protocol layer are almost entirely in IETF. And there's some intersection, of course, between that and W3C, but a lot of that work happens at IETF. IETF does a lot of baseline-level protocol work as well. The one final big piece that impacts on Chrome is inside the organization, there's a technical committee, TC39, and that is where JavaScript itself as a language is driven. And we spend a lot of time there. A lot of JavaScript functionality happens there, of course.
12:37 SHARON: And that's folks in VA who might be working with that. OK.
12:42 CHRIS: Yeah. I mean, sometimes JavaScript language features go a little bit broader than that, but definitely they're the ones who spend the most time there. There's other organizations we spend time in as well, like Khronos, for example, for some of the graphics work. It ends up surfacing inside WebGPU, but it also-- like, there's a bunch of work that's going on in a base layer somewhere else. And so the boundaries aren't always a bright line, I guess, is what I'm trying to say.
13:10 SHARON: Mm-hmm. With the boundaries, so is it ever the case where two different organizations have a spec for the same thing, and as a browser, you now have to pick which one you implement, or are they pretty--
13:28 CHRIS: Are they pretty separate?
13:28 SHARON: Separate, yeah.
13:28 CHRIS: Do they do they pick and choose? It's a hard question because occasionally that happens. It usually doesn't last that way for very long. Sometimes a solution will be developed at one place, somebody else starts developing a solution in a different place, and one of them wins in the marketplace or in the standard space, at least. Usually, because the core goal here is interoperability. Engines have to choose at some point what they're going to implement. Sometimes there are features that get developed in a whole bunch of different places, and they don't ever really get completely chosen. Like image formats is a great example where we support a set of image formats. Safari supports a set of image formats, Mozilla supports a set of image formats. They're mostly the same, but actually, not quite. And some of them are implemented, are specified at different places. And same for video, same for audio, even. Sometimes those get overlapped in a way. Usually, if you were going to come up with a real new feature or functionality, probably you're going to get a community behind it, and that community is going to end up collecting in one place.
14:47 SHARON: Are there-- a lot of these, it seems like there's a collection of browsers that are implementing and follow these certain specs. Are there ever browsers that operate separately? Is this internationally universally the case? Or are there-- if you go somewhere else, maybe they'll have different standards organizations that--
15:10 CHRIS: I think for browsers particularly, you-- there are definitely-- all of the browser developers, all of the browser engineers, typically they are showing up to the same venues. However, they may be implementing different things sometimes. Sometimes those are deliberate choices. Some browsers may heavily veer over onto the we want to ensure that we are making the absolute most private experience possible. So they want to disable any feature that might be used for fingerprinting. Other browsers might choose to be a browser that is the best immersive web browser or something like that and take that as their goal. So they choose a different set of things to implement or a different set of choices to make in the implementation, even. I don't think you will usually-- certainly, the goal of the web is to be a worldwide web, and we have members-- at the W3C, there are members across all of Europe, Asia, the Americas. The bulk of the world there. There are a few places they haven't really gotten into as much as they-- I think they should, but those are typically not places that have been developing the engines underneath the web. And the top level, like the browser UI, the browser chrome-- lowercase c, chrome, there are a lot of choices you can make there. Most of those are not hard-set for you in a specification because how you organize favorites or something like that is up to you.
16:45 SHARON: Mm-hmm. We have only standards. We have all these specs. Chrome, a browser, implements a bunch of them.
16:57 CHRIS: Mm-hmm.
16:57 SHARON: Who is responsible for making sure it's done correctly?
17:04 CHRIS: A great question. I think for an individual specification, it's usually pretty straightforward. Now, this is very different than 20 years ago-- even 10 years ago, I would say. Testing is a heavy piece of requirements in most standardization. So if you end up with a W3C recommendation, there better be a test suite for it. You better be able to conclusively test and prove that the implementation followed the spec. 20 years ago, not so much, to put it mildly. But at the same time, I think there are choices about what you implement-- which pieces of the spec or which specifications, even, that you implement. And there's not really a right or wrong there, necessarily. There's not a meta spec that says, OK, this is what a browser is. Here are all the pieces, here are all the pointers. You have to implement all of these things, and once you've checked off all the boxes, you're done. And that can be kind of challenging sometimes.
18:08 SHARON: Mm-hmm. Right. Yeah, because sometimes it's-- the testing makes sense. So when you say there's a recommendation, that means there's a spec. And for it to be recommended means that it's been approved and now it's a standard.
18:20 CHRIS: Yes.
18:20 SHARON: OK.
18:20 CHRIS: Yeah. Recommendation, by the way, is W3C parlance for standard.
18:28 SHARON: OK.
18:28 CHRIS: They just-- they don't ever call anything a capital S, Standard, they call it a capital R, Recommendation. It's a weird thing.
18:33 SHARON: Maybe it feels a bit less-- It's a bit less strict-sounding.
18:40 CHRIS: Yes. I mean, the W3C has been around for 30 years this year. So they've been at this a long time, and when they started, it really was not a standards-developing organization in the way that ISO was a standards organization. Very, very strict about how things were laid out, what requirements there were, that kind of thing. W3C has had to back its way into that.
19:07 SHARON: Mm-hmm. OK. You mentioned a lot of the types of members who are members of the W3C. So when it comes to new web features, where does the push for new specs come from? How much of it is from companies like browser vendors, and how much of it is from web developers, which, in certain cases, is also the same-- are the same people also happen to be browser vendors themselves. But if you're just some random web developer and you want a new spec, how likely is that to happen?
19:37 CHRIS: This is an interesting problem that we've had for the entirety of the web as far as I'm concerned. Because one of the things that-- it's hard to really internalize because everyone who's on the Chrome team is very technical. Understands like what we work on. Heavy engineering backgrounds, usually. And at the same time, we have to remember, we're usually not web developers. This was something that I had to learn when I went and started diving down deep into audio, was I was more of a browser engineer than I was a web developer. And it was neat because I got to flip around and be a web developer and learn how to do all these webby things and not worry as much about what happened underneath it, although I did for audio because audio is really weird.
20:29 SHARON: Everything's really weird.
20:29 CHRIS: Everything's really weird, but audio has some very specific-- digital signal processing was surprising to me because it was not something I was ever good at before. And it has some interesting side effects. But I think the hard part even today is largely in order to get a web platform feature implemented, you're going to have to end up getting at least one of the browser engineers-- browser engineering teams, implementation teams interested in doing that implementation. Or contribute into it. I mean Chromium and WebKit and a Gecko are all open projects, so theoretically you can write a bunch of code and contribute it and it'll get accepted. The hard part is setting those priorities is not a clear and obvious, here's exactly what it takes to get on board, or, here's the key to getting your features implemented. I think that all of the browser vendors pay attention to a set of people. We certainly pay attention to a wide set of people. We talk to a lot of people who have different web developer backgrounds. I mean, we spend a ton of time talking to other web platform consumers. We have whole divisions, and our marketing folks largely do this, they don't do traditional marketing-- outbound marketing. We have a lot of developer relations people who spend a ton of time talking with people who actually write code. And in fact, our DevRel team largely is more about writing code than-- writing web code than writing engineering-- like code that's going into the browser. At the same time, if you're just a random web developer out there and you're like, I really wish I could easily format this text in this way or something like that, it can be difficult to get that running. There are a number of incubation venues where you could raise it. I co-chair the Web Platform Incubation Community Group at the W3C. That's one place to do that. But fundamentally at some point, you've got to get somebody behind you saying, oh yeah, that's a really good idea, and here's what it would mean in terms of implementation, and help work toward that. There have been a number of other efforts to try to give people on-ramps like that. And there's another effort I've been involved with called the Web We Want, which is a place that a site you can go to and basically just say, I wish I could do this. Sometimes it's already something that you can do and you just don't know how, but most of the time it's, oh, yeah, that would require a feature like this, and we file it away, and those of us who are part of this project try to pass it off to the other engineering teams and see if anyone gets interested in driving it. The W3C also has a lot of people who aren't browser engineers. I mean, browser engineering companies are, like, three. So all of the other-- I think they're currently riding around 360, 370 members. All the rest of those are some other kind of company. Sometimes the specs they're interested in, they're not even browser specs, though. They're about how to do digital identity in a decentralized way or something like that. That might end up having a browser API attached to it somehow at some point, but isn't fundamentally about that. It's about something very different.
24:00 SHARON: As the use cases for browsers expands, are there more non-browser-specific cases that organizations like the W3C are covering now?
24:13 CHRIS: I think definitely there is a recognition at the W3C and other places too that the web is more than just about what code goes in a browser that you can use. There are pieces of that that are important and need to function on the backend between two clients that aren't browsers, specifically, that might be some other kind of web system. And I think that expansion is good and healthy. Like looking at the web as more than just a bunch of HTML files delivered over HTTP and what you can do inside those. At the same time, that's a really critical core to get right and for us to keep iterating on and expanding on and making more powerful as a platform.
25:01 SHARON: That's the first part of the life-- the Google Talks life of a spec, I guess. So there's some ideas come from people out in the wild. Browser vendors, websites-- of the browser vendors who also have websites kind of thing. And then it sounds like actually getting it done is very messy and hard and--
25:24 CHRIS: It's not-- it can be hard because it's not always predictable. And it's messy because there's no single path to success. There's also-- like sometimes it helps because-- well, I mean, take Google as an example. Yes, we build Chrome. We also have a bunch of really, really important web properties and a bunch of engineers who build those, both on the frontend and the backend.
25:48 SHARON: What are examples of some web properties?
25:53 CHRIS: YouTube.
25:53 SHARON: Oh, properties like that. OK.
25:53 CHRIS: Properties that are built on-- applications and services that are built on top of the web platform and frequently use the browser as a delivery vehicle for those platforms. And those are really-- those can be really healthy partners to have because they could say, hey, I can't do this, why? And we can have a high-bandwidth conversation. It is important not to get stuck in the echo chamber of that, too, and to reach outside that a lot, too.
26:26 SHARON: When it comes to the end of a spec. So actually, maybe before that, what are some ways that specs can evolve and change? Because obviously, use cases are browsers, internet. Tech at large has changed a lot and changes relatively quickly. So it's a likely scenario that's something that you initially started out with a spec for is maybe no longer relevant needs updating. What does that look like? Does it often look like changing something that exists? Deprecating and creating something new? What's that like?
26:55 CHRIS: All of the above. So there are some really good examples of how things have evolved over time and become less interesting and less compelling. I think one of the most important things to recognize is that anything that requires getting to a standard is probably going to take a whole lot longer than just writing a bunch of code and shipping it. And like we frequently make the point inside our team, this is a much longer cycle. Like, you can't join the Chrome team and expect to land a standardized feature from idea inception to shipped, capital R, Recommendation in a year, even. Like a year is not anywhere near enough time to have this happen. I've never seen it happen that fast. I've seen examples of specific features that there was a strong community behind, and they all coalesced and they got a shipped implementation, and then a second shipped implementation, and most of the way to recommendation in roughly that time frame, but it's also rare. Like usually we're talking multiple-year cycles on these. And that can be somewhat challenging, particularly when, as you pointed out, things change. A good example of this was early in the arc of the WHATWG, there was a feature added to HTML at WHATWG called AppCache. And it was a way to provide client-side caching-- like control a client-side cache of a website. So as a website, as somebody who wrote stuff on a web server somewhere, you could say, this is what makes up my site, this is how to control different parts, or this is how to keep different parts of it on the local client once you've been there so next time, it's a whole lot faster. And it was a good idea. And unfortunately, it got codified and implemented across all the browsers at the time right at a period of time when the web itself was changing pretty dramatically. And it ended up being a feature that, frankly, you tripped over it more than you could effectively use it because it gave you a nice static cache of files if that's what you needed, but if you were implementing this really dynamic HTML thing that was doing loads of requests to and from the server and you didn't know whether to make those requests or not, it was really hard to use and ended up getting in the way a lot of the time. And eventually got replaced with a different feature called Service Workers that is much, much more powerful and inserts itself into the chain at a different space than AppCache did. But AppCache lived in the standard for a long time before it finally got deprecated and pulled out. And it took a long time for those cycles to happen and to get the new solution up and running because of that. So really, I guess I'm saying there's no easy answer to that. It does happen. It usually requires a lot of people getting on board with this and seeing-- getting on board with a particular feature change and seeing how the world can be made better.
30:30 SHARON: Yeah, because I work in the navigation space. So not much direct interaction with actual aspects and standards, but you see things that-- the effects of them. So for example, people across Navigation will grumble about document.domain for engineering reasons. And it's like, OK, this would be nice to remove, but how? Because these aren't all also people who are familiar, maybe, with the process of all of this. So in this specific case--
30:54 CHRIS: So, I mean, features like that I would say, well, start out by looking at where it's actually specified. Go there, see what current-- what the current understanding of the world is. So go to, in this case, WHATWG, look at how is document domain specified. Are there open issues with it? Do other people see this as a problem? And then also, really consider the use cases of it. And the more data you can build about how it's used today in the wild-- used or misused, for that matter, can be really helpful because sometimes, while people are really, really dependent on a feature, but they're dependent on it for a totally different reason. My favorite example of this was way, way back in the annals of history, Mozilla or Netscape at the time implemented this blink tag. And the Internet Explorer team decided to out-blink blink, and they created a tag called marquee. And marquee-- it was absolutely insane. It literally did create a scrolling control-- like a scrolling Broadway marquee kind of thing. And it was because Microsoft had a built-in control they could reuse to do this, it was cheap and easy to make something super flashy, so they did it. I think I was technically on the team at that time, but I had nothing to do with implementing this, so don't blame me. But an interesting side effect was they could do a vertical marquee, and it stacked the letters vertically. And it turns out, this was really interesting to use for some types of scripts that were vertical instead. And this became a very, very-- I think it was in Korea, it became very, very entrenched, that people would use marquees to make specific banners because it was the only way to format the text properly at the time. And it took forever to disable this feature in Internet Explorer, which was the only browser, I think, that ever truly implemented the full marquee thing, although Chrome did actually-- does actually today, I think, still have an implementation for marquee. If you go and search marquee on Google Search, I think it does something interesting. So something to try out later.
33:18 SHARON: OK. Yeah. Yeah, the thing about every single one of these videos is you find out something interesting and you're like, oh, OK. Like-- I mean, I'll ask questions relative to what I'm familiar with, and then I'll be like, oh, that could really improve this bit in what we do, but all of these are like career-long projects.
33:29 CHRIS: Yes, they are.
33:29 SHARON: So it's like, hmm, OK.
33:36 CHRIS: There are loads of things to do always.
33:36 SHARON: Yes.
33:36 CHRIS: Haven't run out yet.
33:42 SHARON: Yes. OK. It feels like with a standard kind of thing, there's the "XKCD."
33:47 CHRIS: Mm-hmm.
33:47 SHARON: The situation.
33:47 CHRIS: Oh yes, the classic.
33:47 SHARON: How--
33:47 CHRIS: It's 386, I think?
33:55 SHARON: Oh. It's like 9-something. Anyway. Does that happen much in the browser space? Because there are clear organizations, and they have relatively clear boundaries on what they do.
34:10 CHRIS: I don't think that particular-- so the "XKCD" we're talking about--
34:10 SHARON: We'll flash it on, we'll flash it.
34:16 CHRIS: Is the one where we have 15 competing standards. They're all wrong, so now you have 16. Usually people are a little bit smarter than that now because we have such a long history of doing exactly that. Usually people look and take what is already there and figure out, well, what's the best path to start from? So you don't end up with 16 things, you end up with 15, and number 13 is actually a version 3 or something that is a lot more powerful. Hopefully. Maybe not. I think mostly people have finally at this stage of trying to build interoperable things recognize that building on things, even if you're deprecating features and adding new features, is probably an easier path than simply starting from scratch every time because you end up with this legacy of things you have to support for a certain period of time, too, then.
35:16 SHARON: Right. With the evolution of specs and standards over time, a lot-- like you mentioned, a big part of it is for interoperability.
35:22 CHRIS: Mm-hmm.
35:22 SHARON: Did the push for-- did the need for interoperability come more from browsers who were trying to do what other browsers were doing? Or was it more from web developers who had to have multiple versions of their website for each browser? Or was it the three browser vendors who were on each side of that?
35:46 CHRIS: I think it was-- both of the first two-- so I'll say, web developers from the very beginning were frustrated by the fact that their code wouldn't necessarily work the same in multiple browsers. I'm sure any web developer in the mid to late '90s would have really given me an earful as an engineer on the Internet Explorer team about these interoperability problems. The tough part is you end up with this entrenchment, too, because your code did something-- people wrote code to work with that. Even if you're wrong, changing it causes compatibility problems. So how do you know what to change to? And I think that was really what started solving the problem, was when Microsoft was dialing down its investment in the web anyways, the other browser vendors really did start coming together with WHAT Working Group as the basis of this and start writing down, OK, this is the way it should actually work. Let's all try to do this. And a lot of the time it was, well, this is what Internet Explorer does, and most people expect this, so let's do this. But in a number of cases, it would be, well, the sane and rational thing to do would be this. So let's write it down, and all the rest of us, let's do this, and then let's try to get the IE Team to support that. And I think the approximation of how do we actually just have one spec that says what you should do was the most powerful thing in that evolution of getting us to actual interoperability.
37:30 SHARON: What's a rough timeline on some of those events?
37:30 CHRIS: Oof. Well, so we were in deep in the browser wars in the mid '90s. And WHATWG started in 2004. So it was probably-- it was the late aughts, probably. It was a good 10-plus years of frustration with not having a really interoperable implementations to finally getting a single way of doing things. And even today, there are always interoperability issues across browsers. I think the biggest thing-- the biggest difference today is those are seen as problems that need to be solved and solved relatively quickly. If you find implementation differences in a particular piece of CSS, for example, go submit it to that spec, to the relevant CSS spec, and you'll probably get some action on it, and you'll probably see implementations get corrected.
38:39 SHARON: Oh cool. OK. Slightly unrelated to that, how does blink intents fit into all of this? Is that for things on the path to specs? Because that seems more, from what I understand, accessible to an average random software engineer than all of this W3C member situation.
39:02 CHRIS: Well, I mean the interesting part is there are two sides of the same process. So the blink intents process is something I'm also deeply embedded in. And part of that is, we actually needed to make sure that the intense process dovetailed with the standards process. So you shouldn't be able to get all the way to an intent to ship without having gone through the right set of steps in doing an incubation out in public, trying to get other community members engaged in your feature, commenting on your feature, having other browsers look at this, other engines look at this and say, oh, that's a sane, rational way to solve this problem, maybe you want to do this or this, whatever. And getting groups like the Technical Architecture Group at the W3C to review it. Getting some broader horizontal reviews around internationalization or the like there. So the intent process is basically designed to be the engineer-focused, here's the set of steps to go through, but some of those steps definitely point you off to, here's where you have to go, write down an explainer, publish the explainer, ask for feedback on the explainer, ask the tag to review your explainer and/or your spec, and things like that. So it really-- it's intended to be the programmatic guide for how to walk through building a feature. It doesn't mean you get to short circuit all the other stuff about getting people to buy in your standard and that kind of thing-- your proposed standard, I should say.
40:45 SHARON: Right. Yeah, there's a good DevRel video about an overview of blink intents that'll be linked below.
40:51 CHRIS: Yeah.
40:51 SHARON: Just now you had mentioned that in the 2000s, variously, interoperability was a huge headache, and that was probably a rough time for everyone working on it. So what is the equivalent challenge today in this space of web?
41:11 CHRIS: I mean, I think that there's still-- there are still interoperability challenges. Like we can't ever-- as long as there's different code, there's going to be differences every once in a while. I think probably the biggest challenge is around things like the set of features that are implemented are still different. Priorities are different in different browser engines, and that can make challenges for people who want to work on one bleeding edge or another. I think there are areas of the web platform that the investment from different vendors is more symmetric and equal. Cascading Style Sheets is one of those, for example. JavaScript Engine-- JavaScript language is one of them where it's not like the engines all work in lockstep, but they are closer together and what they contribute there. There are some areas where Google may invest very heavily in something and the other engines don't, or vice versa. There are areas like we've done a lot of device connection with the Fugu Project that the other browser engines aren't really bought off on as something that should be part of the web platform. We think it should for reasons. You can build really powerful stuff with it, but they may not-- and they may not implement it. And as a web developer, that can get a little weird. And it can certainly get a little weird when you end up, at some point, if you want to rely on this as a web developer, you have to tell people, well, you're going to have to go use Chrome, or you're going to have to go use Safari or whatever because they're the only ones who implement that feature.
42:49 SHARON: Mm-hmm. With the number of features pretty much monotonically increasing, it gets harder and harder to probably implement a browser. And browser people love more than anyone, I think, that to have multiple rendering engines and a variety in this case, but at the same time, as the standard gets higher, it becomes less and less feasible for anyone to make a browser. A few years in, I still barely understand certain parts of the overall navigation thing. I'm like, oh, maybe understanding some parts of it. So what is the trade-off there between having more features and fewer different implementations of them?
43:37 CHRIS: I think one of the challenges in how this will play out in the future really does have to do with-- it's related to what I was just saying about what you end up with is a choice of which features get implemented. Not so much a, well, there's just incompatibilities in how they're implemented, but it could easily be, well, I'm only going to implement this set of image formats and I'm not going to implement any of these APIs, I'm just going to implement this set. And I think that we see this in some places today, and we don't really necessarily even notice it so much. Like my car has a web browser in it. It probably isn't quite the same as the one in my desktop computer. We've gotten very used to our phones having a really, really modern and updated browser on it. But at some point, that might actually be, why am I putting a supercomputer in my pocket when I just want it to text messages and make phone calls most of the time, but I also want it to have a basic browser experience? That might be a choice, right. You might have different classifications of devices or things like that. I do think that we'll see more areas where there will be subsections of the web that are implemented. I would like to see, for example, electronic books to be really more blended together with the web in a lot of ways. But at the same time, it is my Kindle device, the thing that I toss in a backpack and abuse and carry everywhere, and all I wanted to do is have a battery that lasts forever and a display that's easy to read, does it really need to be running on a high-end mobile processor in order to not fall over? I'd sacrifice features for that. And I think you'll see people start choosing feature sets for that reason.
45:43 SHARON: Yeah, I think there's a general trade-off consideration more like in the ether of as browsers become closer and closer to operating systems, because they run applications, is that what people want? Like, some people want that, some people don't. And there's no right answer, but--
45:58 CHRIS: Yeah, there's no real right answer. And I think that, to me, it is really important to have a system that can scale to doing that. I think the interesting bit is that there are places where you don't really want it to have to do that all the time. And, like, I have a wide variety of Chromebooks littering my desk and my house. And some of them are-- they're from they're some of the very original Chromebooks. And they may not be getting updates anymore, but they're still actually a decent web browser. Still useful to use. And at the same time, if you read the specs of them, they would be laughably short by today's standards. Definitely not what I would go by today. And I think recognizing that and providing more of some dials in there would be helpful. I think the web itself got into some bad patterns about how it included other scripts and things that were causing problems more than solving them. And we just relied on Moore's law for a little bit too long, but I think we're coming back from that a little, so hopefully we'll have a more positive future there.
47:22 SHARON: Hopefully. Yeah, I'm curious to hear about how things have changed in the time that you've been working in standards, because part of the thing about-- that's cool about working on browsers in general is that they're new enough that there are people around who've been there from-- not maybe the very beginning, but quite early on. Like, I work with a good number of people who were around before the launch of Chrome, which is like a huge--
47:43 CHRIS: Oh, that little upstart, yes.
47:43 SHARON: Yeah. Kind of world event. But because the entire lifespan of all of us is so short still, like people who were around at the beginning are still around. Like I was in a meeting, we were talking about some isolation features. And they were like, yeah, back when we were designing the web, we made some mistakes and now there's footguns. And it's like, oh, these people were just out here like designing the web, right?
48:07 CHRIS: Yes. I mean, I think that there's-- the one thing I will say, as somebody who was there, some of the very beginnings of it, there's an inclination to look at it through today's lens, and you think of it as, oh, you're out there designing the web. And I'm like, well, I was-- when I first started this, I was an undergraduate student, and we were just writing some code because it was fun kind of thing. Like, designing the web sounds so top-down overview, knew exactly what we were doing.
48:43 SHARON: Right.
48:43 CHRIS: And I don't think that's necessarily true. But I do think that there were some powerful ideas there that it-- it's so hard to explain how the context was different. When I started working on the web, there literally was no interconnected like, I want to learn some information about something. Well, I have to go to the library and look it up in the paper-based card catalog. Like literally, that was the way you did things. If you wanted to do it online, your best bet was CompuServe.
49:15 SHARON: What's that?
49:15 CHRIS: And-- exactly. Like, it's not-- there wasn't a global system for doing this, and there wasn't the underpinnings of that either. And that was what was so powerful about the web, was, hey, you could create this. You don't control it. There's random stuff everywhere and people can just start offering it up on websites. And hyperlinking to it and nobody writes the card catalog, which was actually a super powerful idea at the time. And very new. And today, this is just-- this is the sea we swim in as fish. We don't really even notice it anymore.
49:55 SHARON: What's the kind of stuff you were trying to get into looking up at the library? What were you-- what kind of web stuff were you--
50:01 CHRIS: Oh, I mean, I think there are all kinds of wild stuff. Like when I-- actually, when I was a few years in, I moved to Seattle, and I took a course at the local college. They had this-- still have, I think, this continuing education stuff. And people could teach random courses on things. And I took one on learning to play the didgeridoo Australian wind instrument. And part of this, the guy who taught it, he taught us how to build them, too. And they're pretty easy to build. Like, you can make a didgeridoo out of any tube, basically. And he taught us how to build them out of bamboo, too, because you can knock the nodes in the middle of a piece of bamboo out and it's a nice tube, and it's very natural, sounds really great. I still have several bamboo didgeridoos. But I wrote this web page very early on-- it was on GeoCities, that tells you how old it is-- on how to build one of these. And this was while I was at Microsoft. And for years afterward, I would get these-- I'd get these emails from people because my email address was in it, foolishly. I would get these emails like, hey, I read your page, is this great. Do you know where I might get some bamboo here in Finland or something? And I was like, no, I don't, but thanks for stopping by. But it was neat because I put that information out there just in case somebody might care, and they found it and they did. And by contrast, I don't know, about five or six years ago, I started learning to build ukuleles, which is a much more intensive process. You don't just knock the holes out in the middle of the bamboo, but there's a lot-- like, it's so much easier to find this kind of information. There's YouTube videos all over the place about how to do each and every step. There's instructions online. There's whole communities and forums of people who you can easily discover who will help you walk you through any part of this process. And it's amazing. I mean, like, if I want to learn to change out the oil filter on my leaf blower or something, there's probably a video of someone doing it on that exact model that I could go look at and say, oh, that's where it goes or whatever. And just that amount of information is stunningly more accessible than it used to be.
52:35 SHARON: Yeah. And if anything, there's the opposite problem of curation and how do you find the one you want?
52:35 CHRIS: Absolutely. Yes. Absolutely.
52:40 SHARON: I was making a buttercream-- a Swiss meringue buttercream for a cake and it wasn't working, and I had to watch, like, 10 videos till I found like a tip that was like, oh, it's--
52:46 CHRIS: Yes.
52:52 SHARON: --that was happening.
52:52 CHRIS: Yes. Choosing the-- finding the high-quality information, I think, is still the hardest problem.
52:59 SHARON: Mm-hmm. Right, OK. What has been the nature of your work in specs and standards over time? Presumably you didn't start on the advisory committee of an organization.
53:13 CHRIS: I mean, I started out-- I started as an engineer. Like I co-wrote the Windows version of NCSA Mosaic, one of the really early web browsers. Went from there to Microsoft. Got onto the IE team. Was on the IE team for about 15 years. Several years as an engineer, and then I switched over to be a program manager because I wanted to have broader impact. And partly because of standards-- actually, in fact, mostly because of standards, because I was spending a bunch of time on stylesheets. I did the first implementation of CSS in a browser. And I did all this work, and then I was spending a bunch of my time, about a day a week worth of time working on the spec. Like, working together with the other implementers at the time and the spec editors at the W3C. And it basically-- like, it was eating up my coding time. And my manager pointed this out to me, and that's what prompted me to become a program manager instead. And I think for a very long time, I was in the-- I would edit the specs or write things-- like help guide how the features were implemented. And then started getting into-- probably after I came to-- well, around the time I came to Google was really getting into more of the, this is how-- like, these are the processes we should put in place for doing specs and standards so that we can make them consistent and reproducible and consistently similar quality, and then hopefully raise that quality, too. And I think despite also occasionally jumping down and working on web audio pretty deeply, writing the Web MIDI spec, stuff like that, consistently bringing this back to, oh, we Should use this as a pattern to try to make everything better.
55:13 SHARON: Mm-hmm. OK. Very cool. Yeah. So for people who work on Chrome at large, such as myself, what kind of thing do you think would be more helpful for them to understand about the overall spec and standard process or role in the browser? Because if you don't work on something that directly has a interaction with that kind of stuff, it's something you barely have any idea about.
55:47 CHRIS: Yes.
55:47 SHARON: So I think people who are in Blink or Web platform might be a bit more familiar, but for people who do navigation, for example, the non-web platform side of that, you really don't ever see specs at all.
56:01 CHRIS: I think one of the most important things for everyone to understand-- and it-- again, it might seem more relevant to people who work in Web platform or something like that. But recognizing that what we're really trying to do with Chrome as a whole-- with Chromium, definitely, but even with Chrome as a whole is make the entire web better and more predictable and more interoperable and more usable. Because really, this is what I said when I came to Google. I was interviewed and someone asked me, why are you going to Google? And I basically said, well, Google is driven by making the web better because the more people use the web, the more ads and search we sell, effectively, and that's good. I want to make the web better. There's no make the web better and make sure people are buying copies of Windows. It literally is just make the web better. And I think that even for people who are working on functionality or features that aren't directly in a web standard, interoperable, whatever, recognizing that having that consistency across experiences is actually really important for the web as a whole. The way that navigations happen, the set of events that fire, and what order exactly, that has to be consistent across implementations or applications start failing. And if applications start failing, people don't want to build for the web, they want to go-- they'll go build an Android app or an iOS app because it's predictable. And that would be sad for me personally. I'd kind of rather they build web applications. And so it may be really frustrating sometimes that we're dependent on this open-- this open system that we don't control every piece of. Even on places where you think we do control every bit of, but there is a lot of interoperability in how people expect the web to work. And I occasionally use Safari on my iPad. I guess I always use the underpinnings of Safari on my iPad, but there's this-- there is this-- I still expect it to work in roughly the same way. And I think that's an important piece of building the web as a consistent target application for really powerful and useful things is great. I bought a weather station recently. Totally random, right? I bought this weather station and it gives a whole bunch of information-- internal/outside temperature, wind speed, humidity, all kinds of tracking stuff. Rainfall. And it does not have an application at all. It is completely driven through a web app. And I only mention this because their web app is so much better as a user experience than almost any application I've seen of this type. You can rearrange tiles and it gives you this beautiful display and it works consistently every time I've gone to it. Like it's just an absolute great experience. And it's all built on top of the web. And it doesn't really matter what browser I use for it. I've gone to it on my iPad. I've used it for my desktop. Still a great, consistent experience. Looks great on a mobile device. And this, to me is exactly how I would want most experiences. Let's not even use the word apps, just experiences to be delivered in a way that can go across all these device and OS boundaries.
59:40 SHARON: Mm-hmm. Yeah, I'm just thinking about, like, even in the time I've been using the internet, now, you log into Chrome, and whatever you have is available on all of your devices. But once upon a time you'd have different bookmarks on different devices and whatnot. So do you have any kind of like, kids these days don't know how good they have it, kind of?
60:00 CHRIS: I don't know if I would-- I would probably go the opposite way and say, in some ways, it is much harder today. You just-- you have to expect this as an underpinning. And there was a whole era of the web from very early to mid-- early 2000s where you literally could develop everything as if everything was a desktop, 1024-by-768 screen. Just expect that, it'll be fine, don't worry about it. And it mostly worked for a long time, and then it really didn't work. And of course, now you have-- you can always tell if someone did a really good job about building an adaptable layout or if they just based it on a desktop layout or based it on a mobile layout. If they give you giant fonts when you're on a desktop computer, you know where it started. But yeah, I mean, my wife has been working on starting a new business and she's been building together with the website designer building a website for this. And I've been actually stunned because it's fantastic. It adapts really smoothly. It works great on a mobile device, works great on an iPad, works great on a desktop. And I know how hard that can be. And I think that people are finally starting to crack the how to do that in a reproducible way.
61:35 SHARON: Hmm. Right. Yeah, as more-- there's more of a need for it now, you can just throw money at it in some form and, like--
61:41 CHRIS: Well, I think people have discovered all of the patterns to that. And 10 years ago, this was not an obvious, like, this is how you should go about developing applications like this. And I think now, those are built in. They're built into the packages or you're building your website on top of-- or just in the design tools that people use, typically, in a way that they weren't before. And it is very different. I mean, like, you can consider that the web is the new paper, but paper was predictable. In this country, it was almost always an 8-and-1/2-by-11 sheet of paper, and given-- this is how much you could render on a given sheet of paper. And we don't have that as a baseline on the web. You may be getting experience on a very small mobile device. You may be getting it on a huge display screen. And the ability to adapt across those and provide good experiences across them is super powerful, but a lot of work, too.
62:47 SHARON: Mm-hmm. Yeah, very cool. I think-- yeah, in the past I had a team member be like, oh, you should just make some websites and stuff, and like-- I'm like, how do I start? Because I'm very much in the case of browser engineer, not web developer. And there's-- I think when he was-- back in when he was doing it, it was very-- there wasn't much you could do. It was like, HTML page, called it a day kind of thing. And I'm like, there's too many options here. And a lot of so much of it is like, you these libraries that'll do all these things for you, or use these website templates. And you can do less now, too. There's a lot of systems products, I'm not too sure.
63:27 CHRIS: Yeah. I think people have gotten less interested in trying to pack information in every inch of available display screen at the smallest possible rendering resolution, too, which helps.
63:41 SHARON: That was--
63:41 CHRIS: Thinking a little more about, what do you actually need to show rather than how do I cram all this text onto one page?
63:47 SHARON: What era was that?
63:47 CHRIS: I think there was definitely-- even leading into the late '90s, there was this idea of-- like, I mean 1024-by-768 is actually not that many pixels. And so you would have fairly small text. And you had to very carefully use each pixel because if your text was rasterized wrong, it could be really unreadable or overlapping with other things or whatever. And just-- now, even a relatively small physical screen is pretty high resolution. And people are also realizing that, hey, not all of us read-- have that great vision. My close-range vision is starting to go, so I know, like, please don't make the smallest possible font. Crank that up a few sizes.
64:46 SHARON: Oh, yeah. My close vision is OK, but I just don't like it when text is too small, so my text is always huge. All right. Well, I think that's a pretty good rundown of specs. Anything else you'd like to add?
64:57 CHRIS: No. I think it's been an interesting journey. And I will say, just if there are questions out there about specs versus standards, always refer them to me, refer them to the Web Team-- Web Standards Team on the Chromium Team, and we have lots of resources to borrow from there.
65:18 SHARON: All right. Sounds good. Thank you very much.
65:18 CHRIS: Thank you.
65:25 SHARON: All right.