[MUSIC PLAYING]
CHRIS WILSON: Chrome, I
would hope everyone knows,
is Google's browser.
This wraps in a bunch of Google
services and user experience
features.
But Chrome is built on
top of Chromium, which
is an open source project.
And that core open
source project
also gets used by a
number of other browsers--
Edge, Samsung, internet
browser, many others.
Blink is the web platform
engine inside that.
And Blink is built
around the implementation
of a number of features, open
standards-based web platform
core features that we've
all known to come and love.
The last bit is one that Yoav
and and I already mentioned,
which is the Web Platform
Incubation Community group.
We usually call this WICG.
We co-chair this along
with Marcos Caceres
from Mozilla and Travis
Leithead from Microsoft.
And this is the
place where we start
the journey of a lot of
these collaborative efforts.
YOAV WEISS: Chromium is a huge
open source project that's
seeing 90,000 commits
a year from over 2,000
different contributors
working for 55
different companies, potentially
with multiple organizations
inside of each company.
And each one of those parties
have slightly different
interests.
It's also important to
recognize that a lot
of those contributions are
coming from Google employees,
but non-Google contributors are
almost 20% of that pie chart.
In order to make sure that
all of those contributions
from different parties all make
sense, we need an open process.
CHRIS WILSON: If you've
interacted at all
with the Chromium
open source project,
you've probably seen people
talking about intents--
intents to implement,
intents to ship.
These intents are part of
the Blink process, where
a set of trusted
Chromium engineers,
called the API
owners, such as Yoav,
make sure that the
trade-off is being
taken into account by
the engineers working
on different features.
Mozilla has a very
similar process.
Part of our process grew from
the WebKit process as well.
But as part of these
processes, engineers
need to show that there's
industry agreement
or backing that the feature
they're trying to ship
is an important one, and also
that the features' design was
properly reviewed.
That Blink process is not a
replacement for the standards
process, but a separate one.
YOAV WEISS: To recap, the
typical journey of an API
goes from researching
the problem space,
publishing an explainer
with use cases,
designing a solution in the
open with interested parties,
experimenting with
that solution,
and eventually
shipping it or not.
CHRIS WILSON: So what we
would like you to take away
from this talk is,
first, there is
a difference between Chromium
process and standards process.
They work together,
but they're not
replacements for each other.
Our intent process is
intended to make it possible
for us to move the
web platform forward,
even if we have to
go out on a limb
sometimes, but also work
together with the standards
process.
GREG WHITWORTH: And at
Microsoft, we completely agree.
On the move from EdgeHTML
over to Chromium,
we did a full inventory of
some of the goodness we thought
was in EdgeHTML and wanted
to bring over to Chromium.
We reached out to our good
friends over at Google,
and they completely
agreed, because one
of the things we wanted to look
into, that we'll be covering,
is form controls.
And starting up, we were
with accessibility, touch,
and ultimately a
fresh coat of paint,
because when we were
looking at them,
they were pretty
dated as you'll see.
And we'll also be
covering scalability,
extending functionality,
and then ultimately,
as Nicole was saying,
new components.
And then we have this
lovely Windows 95
draggable element here in the
range, which is definitely
in the need of an upgrade.
So we gave it a more
modern splash coat of paint
to flatten it up a little bit.
So hopefully, it looks a
lot better to you as well.
NICOLE SULLIVAN:
And for Chrome, we
decided to experiment
with a little bit
of a different visual detail.
We are showing the selected
portion of the range in color.
We'd love to know
what you think.
This is something we're
still playing with and trying
to figure out what works well.
GREG WHITWORTH: And checkbox
and radio, they're small,
but they're also really,
really impactful form controls.
They're on almost
all of our forms.
And while, again,
there's subtle changes,
those gradients are very,
very indicative of the era
that they came out.
And we've now flattened,
modernized them.
And hopefully, they fit better
in all of your form controls
on your websites
that you're making.
NICOLE SULLIVAN: I believe that
you lit the path for us here.
Thank you.
On Chrome, again, we
decided to experiment
with color for the
selected state.
So that said, though,
we share about 99%
of the code for these elements.
And so that's going to make
the next steps that we're
talking about a lot easier.
GREG WHITWORTH: Another
important aspect,
as we started off with,
was accessibility.
And one of these
things is it really
doesn't matter about the
input modality you're using.
You should be able to use
the control in a good way.
And touch is one of those
things, as you all know.
I've been using the
Macs over at the booth,
and I keep touching the
touchscreen that isn't there.
We have the 2-in-1
Windows devices,
and so touch is very
important to us.
And so we increased the hit
test regions on-- here's Date.
But the control, I think, that
shows this the most is the Time
element, which, as you can see,
here's the current Chromium
one with those
wonderful little tiny
spinners that good
luck trying to touch
those with your fingers.
We now have the similar
pop-up that we have in Date.
And you've got the normal
touch scroll carousel-type feel
to have a good user experience.
NICOLE SULLIVAN: So we
wanted to understand
why form elements are recreated
as sort of a starting point
for understanding what
we could do differently.
The top 10 form controls that
are recreated by web developers
are here on this screen.
The top one is Select.
GREG WHITWORTH: Shocker.
NICOLE SULLIVAN: Yeah, I think
we all saw that one coming.
Checkbox, Date, Radio, and
File, and then a few others
that are used as well.
SPEAKER 1: For the most
part, we can probably
agree that most web
developers do not
build entirely custom
infrastructure and tooling.
Where possible,
developers usually
prefer to rely on
open source tools.
So one way to improve actual
websites that developers ship
are to improve the actual
tools that are being
used to build those sites.
Better open source
tooling can directly
result in a better web.
MDN will soon release the first
edition of their developer
and designer survey
to try and learn more
about the needs and
frustrations of web developers.
With over 28,000 responses,
one interesting result
from the survey was
that 72% of respondents
actively use React, Angular,
or View for their sites.
SPEAKER 2: So how should
we invest in the framework
ecosystem to address both
DX and UX challenges?
We think there's a big
opportunity here for tooling
to help with both
of these problems,
in particular, by
bringing good defaults
and by being opinionated.
So I'm going to
take a moment here
to define this notion
of what we decided
to call a web framework.
It's an end-to-end system
that controls every aspect
from getting started,
everyday development,
through deployment.
It's directly positioned
to impact both UX and DX
by controlling the
server and the client,
the build and the serve, the
dev and the prod environments.
And this is a core premise
of our work in this space.
Through these web
frameworks, we want
to enable developers to
successfully build and maintain
high-quality production apps.
[MUSIC PLAYING]
