[docs] add "What's Up With Web Standards" transcript
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:

committed by
Chromium LUCI CQ

parent
03b736d3b8
commit
08a025f291
docs
@@ -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 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 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 Platform - Episode 10](transcripts/wuwt-e10-web-platform.md)
|
||||||
|
* [What's Up With Web Standards - Episode 11](transcriptswuwt-e11-web-standards.md)
|
||||||
|
|
||||||
### Probably Obsolete
|
### Probably Obsolete
|
||||||
* [TPM Quick Reference](tpm_quick_ref.md) - Trusted Platform Module notes.
|
* [TPM Quick Reference](tpm_quick_ref.md) - Trusted Platform Module notes.
|
||||||
|
985
docs/transcripts/wuwt-e11-web-standards.md
Normal file
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
|
Reference in New Issue
Block a user