UNA KRAVETS: Hello. Welcome to Ask Chrome,
the ask me anything panel with the Google Chrome
leadership team, where we're answering your questions about
troubleshooting, building great web experiences, and the
future of Chrome and the web platform. And some of these
questions are spicy, so definitely stay tuned. We're also taking live questions
on Twitter, Discord, and Slido. You can find the links
to Discord and Slido on the CDS website. And if you'd like to ask
a question on Twitter, tweet @ChromiumDev, that's
@ChromiumDev in one word. We have Jake Archibald looking
out for your questions live, so if your question doesn't
get asked just blame him. I'm Una Kravets, a developer
advocate on the Chrome Web Platform team. And here with me we
have directors and leads from product management,
engineering, privacy, capabilities,
rendering, and graphics, all across Chrome
gathered here today in a meeting at the same time. And I've seen how packed
their schedules are. It's so nice to have you
all here with me today. So to get started,
I'd love for you all to introduce yourselves,
and tell everyone watching a little bit about what you do
and the areas your teams cover. Maybe we can go in order,
starting from Ben Galbraith, and then we can go to Ben
Goodger, Parisa, and Chris. BEN GALBRAITH: Great. Hey, everyone. Ben Galbraith, I lead
product management for Chrome's web platform team. And I've been working
on the web platform or building on top of the web
platform as a web developer since I guess 1995 or so
in various industry roles. And I've been at
Google since 2015 with one year intermission. Happy to be here. BEN GOODGER: Hey,
I'm Ben Goodger. And I lead engineering product
and developer relations for web platform and Chrome. I've been working on the
web since the mid-1990s, initially as a
developer, and then I got involved in
building browsers. And it's just it's always
been so incredible what people can do with the platform. And as the platform has
gotten more powerful, we really see what the future
of computing looks like. So I'm excited to be
along for that ride. PARISA TABRIZ: Hi, everyone. My name is Parisa Tabriz. And I'm currently responsible
for the Chrome browser product engineering and design team. I've worked on Chrome
for about eight years. And first joined to head up
the Chrome security team, and so care really deeply
about security, privacy, and in general building
great experiences for users and developers on the open web. CHRIS HARRELSON: And
I'm Chris Harrelson. I'm a software engineer
on the Chrome team. I've been here on the team
for about eight years. I lead the rendering team,
which is the team that does how you turn
HTML into pixels, and the RenderingNG effort
is one of the things that I was helping to lead. I'm also a Blink API owner. And I haven't been
working on the web since as long as the
two Bens, but I've been using the web since the
beginning, and I love it. And I hope that it
gets better over time. Thanks. UNA KRAVETS: Thank you
all for those intros and for being here. As I mentioned earlier,
some of these questions are pretty spicy, so I think
it'll be fun to just dive in and get started with some
of the spiciest ones. So our first question is
around privacy initiatives and some recent news headlines. And this comes from
Jeremy Keith who asks, given the court
proceedings against AMP, why should anyone trust FLOC
or any other Google initiative ostensibly focused on privacy? And for those who
aren't aware, FLOC is Google's solution for ads
without third party cookies and individual tracking. BEN GALBRAITH: Yeah,
you and I can take this. So first off, I can't comment
on the AMP legal proceedings, of course. But speaking about FLOC,
FLOC, as you probably know, is part of this
broader initiative that we call the
privacy sandbox. And I think it's important
to note that we're not asking for blind trust
with the sandbox effort, instead we're working
in the open, which means that we're sharing
our ideas while they're in an early phase. We're sharing specific
API proposals. And then we're sharing our code
out in the open and running experiments in the open. And in this process we're
also working really closely with industry regulators. You may have seen the agreement
that we announced earlier this year jointly with the
UK's Competitions and Markets Authority regulator, the CMA. And we have a bunch of
other industry collaborators that are working with us. So we'll continue to be very
transparent moving forward, both in terms of how
the sandbox works and its resulting
privacy properties. We expect the effort will
be judged on that basis. Thanks. UNA KRAVETS: Yeah
thank you so we also had a lot of questions around
AMP and Chrome's plans for it. And these were some of
the top voted questions that we got on the Slido. So could you also
speak a little bit about what the future
status of AMP looks like? BEN GALBRAITH: I think I
could take this one too, Una. From the Chrome
team's perspective, we view AMP as an important part
of the web framework ecosystem, as a peer to other
popular web frameworks. And we'll continue to
support the developers that choose to use it. Also want to
highlight, though, one of our goals with the
Web Vitals initiative is to make it easier
for developers to understand how to achieve
things like fast perceived page load times and
stable page layouts regardless of the web
framework that they choose to use, and
to align Google Search with those guidelines. And this was based on
feedback from developers based on AMP and the role that
it plays in the ecosystem. UNA KRAVETS: Yeah,
so another thing that we've seen
headlines about recently is Photoshop and other Adobe
design programs in the browser. And as somebody who
works in UI this has been so cool to see
all these integrations. But we have an
anonymous question here. It says, it's great to
see Photoshop on the web, but isn't this just another
example of a Chrome only web? Why doesn't this work in
Firefox and other browsers? BEN GOODGER: Yeah. UNA KRAVETS: Maybe Ben
Goodger could speak to this. BEN GOODGER: Yeah, I'd
love to speak to this one. And I think this is
an important question, so thanks for asking it. But as we look at the way that
the web evolves and the way the web has evolved over
the course of history, it's actually
relatively rare for APIs to emerge simultaneously
in all browsers. And so part of the process that
we undergo as we work forward on building the future of
the web with the community is to try things
out, to experiment. Understand that we will iterate. Ben mentioned this before when
talking about the sandbox APIs. But we do all of this
very much in open. And we want to just get
out there with some ideas. And with the
Photoshop launch, you can really see what's possible
when we build together a more powerful web. And so I'm fully anticipating
that we will continue to iterate on these APIs. We really welcome
cross browser dialogue. On the shape of those APIs,
we anticipate making changes to them as we figure out ways
to make them a durable part, and ultimately for them
to become standards. So yeah, that's our view. A very open process, a
very collaborative process. But it starts here. BEN GALBRAITH: I also just want
to jump in and add that Adobe has publicly shared their
intent to bring Photoshop to more browsers,
and is working hard with other browser vendors. And I'll also note that a recent
tech preview of a future Safari release included support for
the File System Access API, which is one of the
APIs that Adobe needs. UNA KRAVETS: That's
great to hear. So just in general, is browser
diversity important to you all? CHRIS HARRELSON: I think
I can take that one. This is a topic that is
near and dear to my heart, so I appreciate the question. The short answer is that
browser diversity is actually quite important, because the
web is an open, interoperable, and universal platform,
and browser diversity is part of what makes that stay
the way it is going forward. Competition paired with
the commitment to interop is also a good thing as
it helps to make sure that the web stays and keeps
getting better over time through those operations. And this is actually
one reason we also have efforts like the one,
the Compat 2021, which was mentioned earlier,
in order to increase the interoperability of
browsers going forward. And actually I have
even more good news to share, which is that the
score for Safari on Compat 2021 has increased since we created
the slides for the keynote from 85 to 92, so
progress is really fast. UNA KRAVETS: Wow,
that's awesome to hear. As somebody who builds the web
and runs into interop issues, it's been great to see
browsers working together to get some of these
key APIs normalized so developers can
use them faster. PARISA TABRIZ: Yeah,
I was just going to add to what Chris said,
or maybe emphasize it, because he said it, but I also
feel like competition is just so important for innovation. And so even though
most of my time is very much thinking about
how we can build the best Chrome browser, and
Chrome browser experience, I really think that
it's exciting to see how many browsers
are sort of emerging, and what innovation
comes from that. And so I'll chime
in as well to say I think it's pretty important. UNA KRAVETS: Yeah, I
love that sentiment about innovating and
also working together to bring a better web to
everyone, that's definitely key. So Parisa, I have a
question for you here. This is just around the
review process for extensions in the Chrome Web App Store. There are some complaints
that it's rather long, it takes a week or more. What steps are you implementing
to reduce the review time? PARISA TABRIZ: Good
question and feedback. Thank you for the
feedback on that. So the whole developer
experience for extensions is super top of mind for us. And for sure, the review
process is one piece of that. We continue to invest in it and
try to improve our policies, clarify those policies, and also
make our review process more efficient. And something me
and my team look at are, kind of, mean and median
review time, and sort of what's happening at sort of
the exceptional spaces. So I know over the
past year, we've actually been able to
review the average review time for submitted extensions
to where now even pretty complex extensions are
reviewed and approved in a couple of business days. And I think we're always
trying to improve that, and at the same time, make sure that we
are really keeping the quality bar, and the safety bar,
and the privacy bar really high for extensions, so that
end users can have confidence that something they
get from the Web Store is really high quality. And so thanks for the feedback. We continue to work on it. Proud of the team's progress and
making things more efficient. But of course, as
always constantly trying to improve
that experience. UNA KRAVETS: Yeah,
thanks, Parisa. So we saw in the
keynote that there are a lot of awesome
features launching. And we got a live
question in from Ronier on Slido, with all of these
awesome features, the future of web browsers will be-- the future of web browsers be
in a place where place IDEs? Could we develop our
apps maybe 80% or 90% entirely in the browser? Is that something that you see? BEN GALBRAITH:
Happy to take this. I've been enthusiastic about the
web IDE space for a long time. I worked on a project doing this
in the late 2000s at Mozilla. I think we're seeing the
capabilities of the web expand dramatically. And moments like the
Photoshop preview we talked about and so many
of the other powerful apps that are on the platform
showcase what's possible. I don't know that it's about
replacing conventional desktop IDEs. I think there's room for a
lot of different approaches. But I would expect
in the coming years to see more and more people able
to do their full development cycles using the
pure web based IDE. And I'm really
excited about that. And I can't wait to see it. UNA KRAVETS: Yeah,
I could definitely see that future becoming more
and more of a reality as well. So speaking about
browser diversity, which we talked about a
few questions ago, another popular question that we
had was around mobile browsers. Remember, you know--
here's a question that comes from anonymous, where
iOS comprises more than 50% of devices, what's the
future of the mobile web without real engine choice? How does the web stay
competitive without Apple on board? BEN GOODGER: Yeah, I can jump
in and start to take this one. So on the Chrome team, we
think it's super important that browsers are responsive
to the needs of their users and their developer community. And so that, for example,
drives the investments that we make as a team. We work on performance,
because users tell us they want the browser, they
want the web to be faster. Developers tell us that they
want new APIs, new features. They want us to
fix certain bugs. And so we prioritize that. If you've been
around for a while, you will remember
an era on the web where innovation slowed
down and even stopped when there wasn't
enough development on the browser on the platform. And what got us out
of that funk really was the ability for
users to make choices about the experience
that they want to have. And so that's super powerful. Parisa that talked
about competition and why that's so important. We believe that super strongly. It's important that
users have the choice. And then across browsers
we can think about how to make a better
product for users, and how to respond to
our developer community effectively. So those are the
principles that guide us. CHRIS HARRELSON: Yeah, I totally
agree with what Ben had to say. I just wanted to add
a couple more points. One is that I don't think iOS
is 50% of devices worldwide. There's actually--
I'm always surprised at the diversity of devices
and platforms out there. But regardless,
it's totally true that the Chrome team
supports an open web. And that's why we
work extensively in the open to support
the web success. And an important part
of that is a diverse set of browsers across all
platforms, including iOS. UNA KRAVETS: Definitely. So we also had a few
questions about Manifest V3. Is Manifest V3 compatible
with all versions of Chrome, or at least which
versions are covered? PARISA TABRIZ: I
can take this one. So Manifest V3 was available
to use since Chrome 88. So it should be compatible
all versions after that. We just shared an
update on our timeline for deprecation away from
Manifest V2 a month ago, and that's kind of going to
be a progress as we evolve the extension ecosystem
to Manifest V3, which has lots of security,
privacy, performance updates. The faster people can move
to manifest V3 the better. And so please do that
work where possible. And on all questions
related to, sort of, extensions in Manifest V3 we
have Chromium Desk Extensions and Chromium.org is
a really good place to engage with all specifics. UNA KRAVETS: A follow
up to that question, why is the Manifest
V3 taking so long? PARISA TABRIZ: Yeah,
so I touched on it just like a little bit, but it's been
important for us, as always, when you make these big
changes to really listen to the developer
community, and get their feedback on improvements,
get their feedback on what's working or what they need. And so part of the reason this
transition has taken a while is really to make sure that
we're hearing all those voices, acting on that feedback,
and giving developers time to make these
updates, because we don't want to break a ton of
extensions who are on still V2. And so I would
love to go faster, but because there's just a ton
of improvements in Manifest V3, and at the same time recognize
we have to be thoughtful, especially in sort
of complex times to make sure that people
have the time and space to make the updates they
need to their extensions. And so I'm also eager. Thank you for the question. And one of the things
we're committed to doing is to just really keep
providing updates on timelines, because we will
deprecate V2, and want to just make sure we can do it
in a minimally breaking way. UNA KRAVETS: Yeah,
thanks, Parisa. I really like this
next question. It's a little bit more general. What are some examples of
proposed web platform features that the Chrome team has
declined to implement? And what went into
that decision? CHRIS HARRELSON: I think
I can take this one. And apologies in advance that
my answer is a little bit long, but I think it's because
it's a complicated question. So as I mentioned
in the beginning, I'm the lead Blink
API owner, which means that I work to
help approve shipping new features in Chromium. So let me tell you
about how that works and how it differs from Chrome. So Chromium and Chrome
are not the same thing. Chromium is an
open source project with contributors from many
companies across the board, such as Microsoft, Igalia,
Opera, Samsung, and so on. Chrome is Google's product that
is built mostly on Chromium. And the distinction is important
for questions like this, because when we
implement a feature, the feature goes into
the open source project, whereas Chrome is like
a shipped product that builds upon that code
base, but could potentially have differences where we
flag features on and off. So let me give you a couple
of examples of features where Chrome decided at
the moment, at the time or at the moment that
it wasn't a top priority to implement a feature, but
it was implemented anyway, because someone
else contributed it. One example is MathML, which
will when it ships hopefully sometime soon will allow
all websites to have easy to express mathematics. And that one was actually
contributed by Igalia. So while Chrome didn't feel
like it was a top priority to implement that relative to
other features at the moment, the code was reviewed
and was added to Chrome. Another example is the request
storage API, a recent one that Microsoft is implementing. Again, that's being
implemented in Chromium. And there are also a few cases
where the Chromium owners-- meaning like the code owners,
the people who try to make sure that the code base
is high quality, and sustainable over time-- have decided that there's
too much complexity, and that it would be too
much of a difficult issue to implement at this
time or as designed. And one of those
examples is CSS Regions, which is one that was proposed
a number of years ago. It was ultimately
removed from Chromium. So after a feature
is implemented, it may be shipped
in Chromium, which means that we go through
this Blink API on a process, and then we turn
it on by default. And that is done
as long as it meets the requirements of building
towards a standard based open and interoperable
web platform via consensus specifications. And that process,
as I mentioned, is mediated by the Blink intent
process and the API owners. However, Chromium
based browsers, like Chrome, Edge, Opera,
Samsung Internet, and so on, can and do actually flag
features on and off, which are in
Chromium by default. So hopefully, all of that
long winded explanation helped explain our point of view
towards Chromium and Chrome. UNA KRAVETS: Thank you. Anyone else want to
talk about features? [INAUDIBLE] All right, well, we have a
lot of questions actually that builds on to this
and the other side of the coin about
specific features that maybe you can also
answer this one, Chris. Are you planning to
implement CSS Subgrid? Firefox is currently the only
browser that supports it. CHRIS HARRELSON: Aha,
this is another good one. So Subgrid was-- so originally
the grid implementation was contributed by Igalia also. As you can see
Igalia is actually a really important
contributor to Chromium. And that was added to
Chromium, because we just didn't have the staffing
to implement ourselves. But now we've actually
implemented it as part of the LayoutNG project,
which is part of RenderingNG. And this new implementation is
actually a much higher quality basis that we believe will be
straightforward to add Subgrid to. So that is actually starting
implementation right now. And it's being implemented
by Microsoft contributors. UNA KRAVETS: Thank you. I'm very excited for
that future as well. So I have a question
for you Ben Goodger. Is the Play Store and
Android app compatibility still a priority for
the ChromeOS team? Development seems to have
slowed right down and the API level lags on phones-- or lags phones, sorry. This is from Random Android dev. BEN GOODGER: Yeah. No, no, it's still
very much top of mind. Play listing, for
example, you know, recently have improved
support for billing within Trusted Web Activities. And Trusted Web Activities also
provide a really convenient way to encapsulate your PWA
in an Android environment. So yeah, that has
been and continues to be very much top of
mind for the ChromeOS team. As a platform team
we're very much focused on trying to build a
more powerful platform that enables cutting edge app
experiences, especially on Chromebooks. Sometimes that has us working
on the Android integrations, the playlisting components. Sometimes that's us working
on advanced runtime technology or new web APIs, like some of
the stuff that we have talked about with Adobe, and so on. And so really if
there's something that you feel that
we're missing, we encourage you to just
reach out and let us know. UNA KRAVETS: Great. So we also got a few
questions about Lighthouse, and how benchmarking is
handled inside or upon. This one comes from
Adriano S, what's the plan with Lighthouse and
the Moto G4/G3 connection benchmark? Is this device network combo
still the global average after so many years? CHRIS HARRELSON:
That's a good question. I can take that one. So yes, it actually is. And this is related to my
kind of caveat point I added to a previous question about
iOS, where actually there really is a really wide
variety of devices. And it is true, as
far as we can tell, that a device similar to Moto
G4 or 3G in its capabilities is representative of
the global average. So that's why we have
in the Lighthouse. And if we see that change
through our analytic data, we will definitely update
Lighthouse accordingly. And just this is a good
reminder that there is a tremendous amount
of diversity of devices and network speeds out there. So it's really important to make
sure your site performs well on as many as you can. UNA KRAVETS: Thank you. Another benchmarking question
is about time to first byte. This one comes from Walter Lee. How do you count time
to first byte in CrUX? For example, if the site has
many elements inside of it, do you just count the first
HTML time to first byte or average it all out? CHRIS HARRELSON: Yeah,
this is a-- the Core Web Vitals are quite complicated
and subtle areas. So this is a really good
question to dig into. So time to first byte,
sometimes called TTFB, means the time from when the
user requested navigation to a site until we get the
first bytes off the network. So it's actually even
before we parse the HTML. It's when we get the first bytes
back into the Chrome browser. And another point
to make is that this covers just the main
page resource, and not the sub-resources,
such as images. UNA KRAVETS: OK, thank you. So we had another
popular question that's a bit more broad. But the question is
how deeply will Chrome be integrated with
other Google projects? PARISA TABRIZ: I can talk
about this one a little bit. It's a great question. It is hard to add
in the abstract. But when we think
about Chromebooks, it's Google's browser,
Chromium browser. And we try to bring the
best browser by Google as sort of like a
high level of what we think we're trying to achieve. For me, it always
goes back to like what are the key user
jobs, or user journeys, or developer jobs that we're
trying to serve with a browser. Search is a huge one
for a web browser, doing complex work,
whether that's research or learning, or
kind of, in my case, doing work across many different
tabs with collaborative docs and email, so complex
journeys, shopping. We think about seeking out
information, and consuming it, and that can be like
entertainment or kind of long form reading. And so we always go
back to like what are the user journeys
we are trying to solve. And then we have this
amazing Chromium project to build a browser on and a
lot of other things at Google. Search is the one
that usually comes to mind, and like as search
is innovating and continuing to evolve how that technology
and those products can work, we think about how can we
really bring that to Chrome. So earlier this
year, we announced that we're bringing Lens, which
is a visual way of doing search into Chrome. And we think that can actually
be really useful for shopping or other user journeys, where
visual search as a new input modality than just sort of
text input can be important. And so there's not like a
specific number or proportion I can talk about,
like where we think about bringing Google innovation
and technology to Chrome, but it's something
we're constantly thinking about related
to search and shopping. For me, security is
also top of mind. And Safe Browsing is a
Google security technology that we integrate deeply
into Chrome to protect people from going to sites that
will Phish their data or install malware. And integrating with the
Google password manager, so that we can
actually make it easier to generate strong passwords
and manage them and remove just some of the hard edges
and insecure properties of passwords today is
something we're working on. And so other
security and privacy features as well as just kind
of a whole host of things, but always rooted in how we
think we can improve the user experience, and with
an eye towards kind of other great things that
are happening at Google that we can bring
to the product more so than any specific
number or metric. UNA KRAVETS: Yeah, I love that. So on that thread,
speaking of user journeys, needs, or requests, we
got a question from mtom, is anyone on the
Chrome team looking at building and
implementing a WebSQL2 spec? If not, can we formally
request or get involved? BEN GALBRAITH: You
and I can take this. So we've learned a
lot over the years through WebSQL, and IndexedDB,
and just in general our efforts to build in structured
storage into the browser. We're investing our efforts
now into something called the Storage Foundation API. And this enables JavaScript
developers and WebAssembly developers to implement high
performance file I/O directly on the web platform itself. And when you look at
the challenges involved in having a browser
own and maintain a sophisticated storage system,
like a SQL Engine, and to keep it optimized and
bug free over time, we think enabling this
at the library level makes a lot of sense. And I'm really
excited to see what the ecosystem builds on this. UNA KRAVETS: Yeah, cool. So this is another
live question. This one comes from
Stacy via Slido. Stacy says, hi, I made my own
website through WordPress. Awesome. What are the most
important things I need to do to make user
experience the best it can be? BEN GALBRAITH: Actually, I have
just one thing to say on this. First of all, we love WordPress. We have a WordPress plugin
that we create called Site Kit. And Site Kit has our best
guidance and utilities baked right into it. So all you have to do is
search for Google Site Kit and take a look. UNA KRAVETS: Nice. Any other tips, some UX? BEN GALBRAITH: Don't have
a huge number of UX tips. I do think Core Web Vitals is a
huge part of our guidance here. And Site Kit makes
it really easy to measure your site
on Core Web Vitals and to get concrete tips on how
you can improve Core Web Vital scores. That's a great starting point. UNA KRAVETS: Yeah, data
driven UX right there. So here's a question
from Nicholas Mendez. I haven't heard about the
portals API for a while, is it being abandoned in favor
of the web transmission API? Maybe Chris you have
the answer for this one. CHRIS HARRELSON: Sure, yeah. I actually do have
a lot of contacts on that, because I'm
one of the people who's helping to develop this
shared element transitions API that I think is what the
question is referring to. So portals is not abandoned. We actually prototyped
it in Chromium, and we discovered that actually,
while it's a great feature and it has a lot of promise,
in order to implement it in a secure, private,
and reliable way we actually needed to invest
a bit more in the underlying technology, like basically
by underlying technology I just mean like
the code in Chromium needed to be refactored
in a lot of ways, so that we could support
showing render processes and web tabs in this new
mode that is different from portals to other things. So actually it turns out that
same underlying technology will power not just this feature,
but things like prerendering, another feature that we're
working on, back forward cache, and privacy sandbox features. So we're doing all that
investment right now. But it's going to take
a while to complete. In the meantime, we're
investing in approaches that improve the user
experience over time, but are like a little bit simpler
and perhaps easier to or, hopefully,
very easy to adopt. And shared development
transitions, which if you don't
know of it, is about allowing nice animations
to occur automatically during page transitions
for NPAs and STAs. So we're doing that and we
think that it will pair well in the future with
portals when we're done with that
infrastructure upgrade. UNA KRAVETS: Thank you, Chris. So this next question
is a little bit meta, but we've been talking about
this idea, the web platform. This question asks, how do
you define the web platform, and how has that definition
evolved over time? CHRIS HARRELSON:
OK, I could start with an attempt at an answer. First of all, it's a
bit tricky to define, because the web
is not just APIs, and it's not just browsers,
because if you just have a browser, but
there are no websites, and there are no servers
to serve content, what's the point of the browser? So there's an ecosystem
here of like there's interdependent websites. There are ecosystems affecting
products of many kinds, like frameworks in the
search engines themselves. So all of this together
is like what we think of as the web platform overall. However, at its core,
of course, there is a system of open and
interoperable browser and client side APIs that
the whole thing is built on and allows different parties
and companies to interoperate smoothly with each other. And so I don't think that
particular definition has changed over time, which,
by the way, I would say is an amazing testament to the
quality of the original idea of the web. It's a pretty amazing idea. But it is true that
these APIs are constantly improving and increasing and
the capabilities of websites are increasing over
time, so in that sense the web ecosystem is growing
and defining its new roles in many new ways. For example, the IDE
question, like 20 years ago, it'd be like [INAUDIBLE],,
OK, maybe in the future. But now it's a reality. So that's my answer. BEN GALBRAITH: Yeah, I
just want to build on that if that's all right. I agree with Chris's definition. I think it's similar to
how, believe it or not, how we think about
the body in a sense, because when you
experience life, like where do your
cells in your DNA end and where does the
role of bacteria that you're a host for begin? And I kind of think
of the web platform similarly, because it's emergent
based on all the browsers that are available and
that people are using, and the libraries that
they're using on top of it, and the frameworks that
are used on top of that, and the third party services
that are incorporated into the web experience. And all of this goes
into what I really think is meant by
the web platform, and how users experience
the web platform. It's a fantastic, open,
organic, and constantly evolving platform. [INTERPOSING VOICES] CHRIS HARRELSON: Oh, sorry. I just wanted to add one really
quick point, which is that-- like, Ben, something you said
triggers something in my mind that I think is
important to mention. That on the Chrome Web
Platform team we really think beyond just Chrome, which
is why we're talking about Code Web Vitals for sites
generally, which is why we're
talking about Compat 21 scores across browsers,
because while the main thing we're doing is building
and shipping a browser, the whole ecosystem is
much larger than that. BEN GOODGER: I'll add on. I've used the term
beautiful chaos to describe all of the
innovation and activity that started in the 1990s and
has been exploding since. And I think Chris
is right, there's some things that are static. There are some
fundamental principles, properties that were
baked into the platform from the beginning,
things like openness, things like low friction,
discovery, things like reach, when you have multiple
user agents implementing that set of open standards. Those are all really
powerful things. As we look at the
platform we're trying to find ways to understand
those reveal them more, to emphasize them more,
and help developers build amazing experiences. And so I would really
say as we look forward understand what those
fundamentals of the web are, and then where do you
want the web to go. Like, this is for the
developer community, this is for the
community around the web to decide and chart that course. I have a sort of a
reaction sometimes, I see these people pontificating
along the lines of, oh hey, the web should only be
about this one thing, maybe it's only a
document viewer, it shouldn't be about apps. Well, ever since the advent
of web mail and search, we've had services and
application experiences on the web, so I don't
think you can really say it's not about those
things, because it is. And so, like, as developers
just like continue to step forward, contribute,
share your ideas, share your experiences,
let's continue to make this a super awesome platform. UNA KRAVETS: Yeah, it's
been amazing to see how far the web has
evolved while staying true to its principles. So thank you all
for your answers. Those were great. We got a question
from Simon Bluhm. Are there plans to reduce
the numerous and repeated permission prompts for PWAs,
the progressive web apps? Permissions should be
grouped and remembered for installed PWAs. Question with feedback. BEN GOODGER: Yeah, sure, I can
jump in on this one as well. I know that we're
still, as we've added like a number of really
exciting powerful capabilities to the web, we do feel a
bit of a tension around both the demand to add
those capabilities and, like, how do we
explain these reasonably to the people that are
using the software, and how do we make sure that we
don't overwhelm them with too many requests and so on. The challenge here is really
finding the right settings on the dial of how much to show. We could say, well just
ask when it's appropriate. But what does that mean? This is something where we
are actively studying, like, what for certain
capabilities, when is the right time to ask,
what does that look like? And so we're doing
instrumentation analysis and study. It's a journey. It's something where I feel
like we will make progress over the next year or so. But it's definitely a hard
problem, but something that's top of mind for us. UNA KRAVETS: Thank you. There's also a few questions
coming in asking around, why can't we put PWAs
in the Play Store similar to what we see
Microsoft doing with Windows? And here's a question that
says, a couple of years ago Jake asked this
very panel when are PWAs going to be
listed in the Play Store? When are PWAs going to be
listed in the Play Store? BEN GALBRAITH: I'll take this. Benjy spoke to this a
little bit earlier-- the other Benjy. This is a complex space,
in my view, because you've got the stores, which are
owned and operated distribution channels with policies that
they have for the content that's in them, and then you've
got the open web, which is open and available to all. And so marrying
those two is tricky. And we have technology, we call
Trusted Web Activities, or TWA, which enables developers
to distribute their web content in the Google Play
Store on Android and also on Chrome OS. And we have tools
like Bubble Wrap that make that process
streamlined and relatively simple. And this is currently
our approach. We appreciate feedback. And we're constantly
listening to developers and looking at
ecosystem developments and evaluating our stance. Nothing new to add. UNA KRAVETS: Thank you. We got a live question here
about CSS Houdini APIs, when will the CSS Houdini
APIs for Layout, Parser, and Font Metrics be
ready to use in Chrome? Chris? CHRIS HARRELSON: Sure, I
can answer that question. For Layout, we actually decided
that we could not properly implement and ship the layout
API until LayoutNG was done. So as I mentioned in my
RenderingNG blog post, LayoutNG is coming
to a close now-ish. It's actually probably going
to take into to a little bit next year. And after that, we're going to
come back to the Layout API. And the other two were Font,
and what was the other one, Una? UNA KRAVETS: The other one
is Parser and Font Metrics. CHRIS HARRELSON: OK. UNA KRAVETS: Layout,
Parser, Font Metrics. CHRIS HARRELSON: So
for Font Metrics, we've been gradually introducing
additional Font Metrics directly into the platform. And I'm not-- I don't think there's a
particular plan for a Parser Houdini API. UNA KRAVETS: OK, great. We had another question about
cross browser capabilities. Firefox and Safari are
implementing privacy features, like cross-site isolation. Why isn't Chrome doing the same? Maybe, Parisa, you can
have some insight on this. PARISA TABRIZ: Sure. So let's see. Digging into this question,
first, Chrome super committed to advancing security
and privacy on the open web. It's a personal
area of commitment, and something I'm really
proud of the work Chrome has done over the
past decade plus. And certainly,
there's lots more work to continue to do here, both in
the product and the platform. When it comes to site
isolation, so Chrome launched site isolation,
which is a security feature a couple of years ago. And that advances
protections via sandboxing at the site level. I'm not sure if that question
is referring to that, but that's something that we're
seeing other browsers actually pick up. Now in the privacy space-- and perhaps this question
was talking about privacy and anti-tracking-- we're seeing also innovations
and different approaches to combating this problem Chrome
has a privacy sandbox effort, and what this is a collection
of APIs and features that are all intended to
advance privacy on the open web, but also ensure that we're
supporting really vital use cases for developers,
in particular. And a bunch of features--
you can read more about it at privacysandbox.com. And I know we have some sessions
on that at Chrome Dev Summit. Just one feature that I know
is an active development is called Fenced Frames. And what that is
it's a type of iframe that is more privacy protected
from the actual containing page. So that's just one example. But broadly, we invest
a ton in this space, and very much depend on kind
of feedback from developers to make sure that
we're advancing things in the right way,
and also your support in deprecating APIs and
technologies that we think have been replaced
by improved APIs too. And so thanks for the question. And look forward to continuing
to work together on improving privacy on the open web. UNA KRAVETS: Thank you. Our next question
comes from Lorin. Do you feel the move
from web fundamentals, like vanilla development,
towards external ecosystems, such as React is concerning? How many turtles must we stack? CHRIS HARRELSON: I can start
with trying to give an answer. It's a good question because
there are so many frameworks, so many libraries
out there, and then as we mentioned
throughout CDS this year there are tons of
new web APIs too. So from my point
of view, if you're using a library of framework and
it helps your web app perform well and succeed, that's great. Success and a useful
website is really the most important thing. That being said, the
more turtles there are, the more complicated it is
to make all the turtles not fall off of each other. And there are definitely
performance challenges that are inherent to loading
and executing more scripts, because more bites that
you download, the more JavaScript you running,
the more the V8 has to figure out how
to run it quickly. So less is better, all
things being equal. That's the key point,
all things being equal. The library adds a lot
of value, that's great. So however, we're undergoing
a continuous process of identifying the common things
that a ton of sites want to do. And if a lot of sites
want to do a thing, then we should
consider adding it as a web API, whatever
that thing might be. And so over time we
might add more web APIs, and then that would
reduce the need to download
additional JavaScript to do that same thing. BEN GALBRAITH: I just
want to pick up and add to what Chris was
saying, because I think it's a really fundamental
strength of the web platform and the web
ecosystem that we have this constant innovation in the
frameworks and libraries that are available to build. And it can seem a little
exhausting sometimes, because every time I turn around
there's like some new approach. But at the same time, I think
this pushes the platform forward in a powerful way. And Chris was
talking about what I think is the spectrum that we've
been facing in computer science and software development from
the very beginning, which is developer
ergonomics on one side and runtime efficiency or
performance on the other. And it's not really
clear to me that there's an objectively right place
to be in that spectrum. I think it's a very
individual decision based on the teams and their goals. But what we are trying to do
with the Web Vitals program is provide objective guidance
to the ecosystem on what makes a really high quality
web experience for users, and to let developers measure
their experience regardless of the framework
they use, and they can make their own decisions. UNA KRAVETS: Yeah, thank you. So we are coming to
the end of our session. And I want to make
sure that everyone who's watching this session
leaves with some next step. So I want to ask all of you--
maybe we can go and order starting from Ben
Galbraith over to Chris-- if developers have a spare
hour after the session, what should they go and
look at, whether it's a feature API, or article,
or even something else? BEN GALBRAITH:
Yeah, thanks, Una. This has come up a bunch. But I'm a big UI geek. I've been building
user interfaces with a variety of stacks
for most of my career. And so I am beyond enthusiastic
about the rendering of G-Project, and
everything that's been unlocked through it. So I'd encourage you to look
at a series of blog posts that our own Chris on this
panel made about RenderingNG. And also Una did a
great job of talking about what she and others call
this new responsive, which is rethinking how we
build web UIs based on these new primitives. And I encourage you to study
both her remarks earlier this morning and also broader
videos and talks that she's done, and others have
done, because there's so much that's possible in the
web now from a UI perspective, and it's really exciting to see. UNA KRAVETS: Yeah, thank you. BEN GOODGER: Yeah. And plus one to all of that. That's super exciting. I would say that
across the content that you see here with
Chrome Dev Summit as well as everything else
that you can read about the powerful capabilities
that the platform has grown over the years, what I would
say is, like, as you reflect on, for example, the Photoshop
demo that you saw before, the [INAUDIBLE] demo
that was in the keynote. There's this really
powerful thing that comes when we take our
conventional idea of what an app is, and
then we marry that to this idea of friction-less
discovery and distribution through the web through
links, through URLs. And so without saying
like a specific API, I would just say like think
about where the web is now, all of the amazing capabilities
that it has across UI, across runtime performance,
and APIs, and so on. How can we make truly
special experiences that are easily shareable
that bring people together? That is, I think,
the thing that I am most excited about right now. It's a unique strengths of
the strength of the web. And so I'd encourage
you to think about that. UNA KRAVETS: Yeah. PARISA TABRIZ: Oh,
lots of things. Hard to pick one. I think if B-Galths,
or Ben Galbraith, is a UI geek I'm
probably a security geek. And so maybe really
tactical would be to check out the Issues
tab on Chrome devtools in the security panel. And it's so important to fix
these issues, because I think, you know, Ben Goodger talked
about evolving the platform and pushing it forward,
and part of that is really making sure
that we can not get kind of held back by legacy. And part of that is really
like graceful deprecation, and pushing things forward. And so it's been amazing
to see, for example, the push towards HTTPS adoption. And we have an HTTPS first mode,
and more tools for developers to fix those issues. But I would say check out the
Issues tab in devtools security panel. And if you have no
issues, then that's a very quick call to action. And if you do have
issues then maybe that gives you some things to focus
on fixing and addressing. UNA KRAVETS: Thank you. CHRIS HARRELSON: Cool. And if you don't
mind it's self plug, the feature I'd like
you to go check out is called content visibility. And I'm actually
the one who came up with and led this project. So I might be a
little bit biased, but I think it's a super
cool and very powerful CSS property that
allows you to make it easy to help the browser
only spend time rendering what's on the screen, not the
size of the document. So please try it out and
let me know what you think. UNA KRAVETS: Yeah,
content visibility is definitely very cool. There's a [INAUDIBLE]
post that I may or may not have written about it. So thank you so much, everyone. Thank you so much to
our leadership panel here, Ben Galbraith, Ben
Goodger, Parisa, and Chris. This is definitely a
very fun discussion with some of those spicy
questions mixed in. And thank you everyone
who submitted questions. We have a lot of
great content for you throughout this
week and the coming weeks in our virtual
2021 Chrome Dev Summit. So if your question
didn't get answered, definitely sign up for some
learning lounges, workshops, and office hours for
more one-on-one time. I'll be hosting office hours
and learning lounges too. The schedule is live
at developer.com.com. Thank you again, everyone
who joined me today. And we'll see you online. [MUSIC PLAYING]
