chromium/src
0
Fork 0
Code Activity

[docs] add "What's Up With Web Standards" transcript

Browse Source 
Change-Id: I2d7f4c5b4b61a99539bfffc1350290edd6f14a6b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5889354
Reviewed-by: Sharon Yang <yangsharon@chromium.org>
Commit-Queue: Nigel Tao <nigeltao@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1360305}
This commit is contained in:
Nigel Tao
2024-09-26 01:10:48 +00:00
committed by Chromium LUCI CQ
parent 03b736d3b8
commit 08a025f291
2 changed files with 986 additions and 0 deletions

1
docs/README.md

@ -465,6 +465,7 @@ a video series of interviews with Chromium software engineers.
* [What's Up With Processes - Episode 8](transcripts/wuwt-e08-processes.md)
* [What's Up With Site Isolation - Episode 9](transcripts/wuwt-e09-site-isolation.md)
* [What's Up With Web Platform - Episode 10](transcripts/wuwt-e10-web-platform.md)
* [What's Up With Web Standards - Episode 11](transcriptswuwt-e11-web-standards.md)
### Probably Obsolete
* [TPM Quick Reference](tpm_quick_ref.md) - Trusted Platform Module notes.

985
docs/transcripts/wuwt-e11-web-standards.md Normal file

@ -0,0 +1,985 @@
# What’s Up With Web Standards
This is a transcript of [What's Up With
That](https://www.youtube.com/playlist?list=PL9ioqAuyl6ULIdZQys3fwRxi3G3ns39Hq)
Episode 11, a 2024 video discussion between [Sharon (yangsharon@chromium.org)
and Chris (cwilso@google.com)](https://www.youtube.com/watch?v=HbFe5jvgE18).
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:
- https://docs.google.com/document/d/1OybUD_3V8472I1dRN-7Jb10MwcppPjSYsrQkls1wZQk/edit
Links:
- [What are Blink Intents]
- [How to make Didgeridoos from Bamboo]
---
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.
[What are Blink Intents]: https://www.youtube.com/watch?v=9cvzZ5J_DTg
[How to make Didgeridoos from Bamboo]: https://www.geocities.ws/Area51/4708/BambooDidj.html