 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 Joav and I already mentioned, which is the web platform incubation community group. We usually call this the YCG. We co-chair this along with Marcos Caceras from Mozilla and Travis Leithard from Microsoft. And this is the place where we start the journey of a lot of these collaborative efforts. Chromium is a huge open source project that's seen 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 those contributions from different parties all make sense, we need an open process. 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, which we're a set of trusted Chromium engineers called the API owners, such as Joav, make sure that the trade-off is being taken into account by the engineers working on different features. Mozilla has a very similar process. This actually 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 feature's design was properly reviewed. That blink process is not a replacement for the standards process, but a separate one. 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. 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. So, 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're looking at them, they were pretty dated, as you'll see. I will also be covering solubility, extending functionality, and then ultimately as Nicole was saying, new components. So, and then we have this lovely Windows 95 draggable elements here in the range, which is definitely in the need of an upgrade. So we gave it a more modern splash coat of paints to flatten it up a little bit. So hopefully it looks a lot better to you as well. 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 and 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. So in 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 air 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. 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 gonna make the next steps that we're talking about a lot easier. 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 Max over at the booth and I keep touching the touch screen that isn't there. We have the two-in-one Windows devices and so touch is very important to us. And so we increase 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. 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 the screen. The top one is select. Shocker. Yeah, I think we all saw that one coming. Checkbox, date, radio and file and then a few others that are used as well. For the most part, we can probably agree that most web developers do not build entirely custom infrastructure and tooling. Where possible, developers would 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. MVN 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 Vue for their sites. 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 wanna 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 broad 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.