 I'm Rachel Andrew, Content Lead for Chrome Web Developer Relations, and in this talk I'll be sharing the ways we're working alongside our partners at other browsers and the broader ecosystem to make developing for the web easier and more consistent across browsers. I've been building for the web for well over 20 years. The web has changed a lot in that time, but one thing has stayed consistent. The need to decide which older browsers we should support. There was a time when browser releases were an infrequent thing. New web platform features arrived slowly, perhaps once a year. Five years elapsed between Internet Explorer 6 and 7. Things did not change quickly, which was frustrating when dealing with bugs when there was no new version around the corner. It was possible for web developers, however, to keep track of the state of the platform. The platform was more limited, with fewer features, and it changed slowly. Today, evergreen browsers with frequent release cycles mean that new features land on the web platform every month. Every browser release brings a raft of features and fixes. Features that range from the addition of a single CSS property through to huge specifications such as WebGPU. Users upgrade to these browsers almost without knowing about it. Updating and upgrading software is something that just happens, so the majority of users will be using the latest version quickly. There are so many things landing each month, it's possible for me to write a monthly post on web.dev sharing just some of them. There's always plenty to choose from. New features are landing quickly and getting onto the devices of our users at a pace unlike anything we've seen before. Features are also becoming interoperable much more quickly, meaning that they work in the same way across all browser engines. It's now not unusual to see features land almost simultaneously in Firefox, Chrome and Safari. Last year we saw cascade layers landing in Chrome 99, Firefox 97 and Safari 15.4. The longed for size container queries hit interoperability within a few months of it landing in the first browser. This is exciting, but also poses a problem for developers. With so much landing so quickly, how can we keep track of it all, and how do we decide when there is enough support for a feature to use it in production? When browsers release slowly, developers would lean on the oldest browser as a baseline, as there always seemed to be that one browser that wouldn't go away and that we had to anchor support to. For the platform to move on, we needed to get to a point where there were few enough users of that browser for us to stop providing support for it, or to only provide very basic support using a progressively enhanced approach. We needed Internet Explorer 11, the last of the non-evergreen browsers released in 2013 and never updated, to go away so we could have grid layout everywhere. We wanted Internet Explorer 9 to go away because it lacked support for Flexbox, CSS Multicoll and CSS Gradients, among many other features. We wanted Internet Explorer 8 to go away so we could use Border Radius and Alpha Transparency and RGB and HSL colors. Internet Explorer 6 had seemed so promising when it arrived with new CSS features, but it was missing many key things and had some bugs that could cause elements on your page to not render at all. We were waiting a very long time for this browser to go away, as it was five years before IE 7 arrived. We went back far enough and we needed Netscape 4 to vanish for so many reasons, but especially for those of us experimenting with CSS layouts, one huge problem was the interesting issue where any positioned items would lose their position if the user resized their browser window. This problem was always top of mind for developers, and we even saw campaigns to encourage people to move away from certain browsers that were deemed to be holding back the web. However, it did make explaining browser support easier. The site had to work in that browser as there was no alternative for people who didn't want to change browsers. Today, however, the last of these browsers has gone, with Microsoft ending support for Internet Explorer 11 last year. So using a browser as a baseline doesn't really work today. All engines change too quickly. There isn't time to understand exactly what is available before everything moves on again. We still need to explain browser support, though. We need to make it clear to our teams which features to use and ensure that our stakeholders understand what will and won't work across browsers and versions. We know there are problems in these areas from speaking to developers. In research we have conducted at Google, the top challenges are consistently around keeping up with changes in the web platform and making designs and applications work in the same way across browsers. Developers are finding it hard to understand what has changed and whether it is supported. I represent Chrome, and we know that we are adding to this problem, and have been working over the past year to address it. I talked about some of the things we are working on last year at IEO, and I feel as if we have made some progress. The main communication channels for Chrome are our websites at web.dev and developer.chrome.com. We aim to use those in a way that is clear and consistent, to ensure you know when a feature is experimental or only in Chrome. If you like to learn about the new things Chrome is landing, then head to developer.chrome.com. There are some really exciting features that are Chrome first, but we hope will be becoming interoperable soon. For example, this year, view transitions, web GPU, or the popover API may catch your eye, and you can learn about all of these things in other talks at IEO. We want to share these with you to get your feedback, but in a way that makes it clear these are just in Chrome for now. On web.dev you will find information about features that are interoperable and our guidance on best practices for web development in a multi-browser engine world. You'll find these support panels everywhere, clearly showing what browser support is for that feature. The data comes from the MDN browser compact data, and our team is helping to keep that up to date. We've been bringing the same clarity to our talks at conferences, highlighting the status of the features we share. We've been celebrating when features land interoperably with a series of posts on web.dev. We've heard you say that it's when a feature lands in all three engines that you feel happy to use it. These posts aim to let you know when that has happened. We've ramped up a documentation for the features we launch in Chrome. We're contributing documentation for Chrome First APIs to MDN and documenting our origin trials on developer.chrome.com. You'll find that by the time features land in stable Chrome, there is often documentation on MDN to help you understand how to use them. Because we care about a diverse multi-browser engine web, we celebrate the features landing in other browsers in our series of posts about what's new on the web platform. To improve the platform for developers, we can't work alone. We're working with other browser vendors and other people to improve interoperability and developer experience. While many features are landing across browsers quickly, there are many features that are unavailable or have significant bugs in one or more engines. The Interop project aims to fix these issues in a set of target features. We worked alongside representatives from Mozilla and Apple, along with other partners, to define the set of features in 2022. All browsers then work to land these features. Just some of the features that became available across browser due to the initiative are the dialogue element, allowing the creation of modal and non-modal dialogues with built-in accessibility. Viewport units, with the small and large viewport accounting for mobile UIs where device UI elements appear and disappear. And cascade layers, enabling better management of the cascade, solving problems that developers have struggled with for years. We then repeated the process with an even larger set of features for 2023. You can learn about all the included features and follow our progress on the dashboard. We helped to form the WebDX Community Group. This group focuses on developer experience and how to improve the experience of developing for the web platform. The group includes representatives of all browsers and has two goals. Firstly, to clarify the status of web platform features, specifically what is widely available on the web platform. Secondly, to conduct shared research on developer needs, to facilitate a shared understanding of the problems that developers face between all vendors. Last year, the group conducted research that was used for Interop 2023 planning. Because we know that documentation is important, Google, along with other companies, helps to fund Open WebDX, a colleague and I are part of the governing committee. Open WebDX seeks to improve the clarity of the web platform through documentation and is a major contributor to MDN. We are doing a lot and feel we've made some great progress over the last year to clean up our own act, bring clarity on our sites and by contributing to MDN documentation and to work through the Interop process to make more features interoperable. However, we realize that browser support is still quite difficult to understand. The information about support for individual features and APIs exists. However, developers have to check feature by feature and sometimes combinations of features to be sure that something will work cross-browser. When developing, you need to figure out the feature status of large sets of features and understand how they align to the baseline of browser support you have set. And you have to figure out that baseline too. How far back should you go before deciding that it's okay to use something without a fallback? I opened this talk by remembering the key browser versions we used to tie our understanding of support to. Without the line in the sand that a key browser version gives us, it's hard to be clear about what our line is. A lot of time can be burned up by each project team, trying to figure out when it's okay to start using things. We felt it was important to provide that line in the sand, a position where you could see which features were safe to use and which would need more consideration to work well across all browsers. And we're working to create it, along with other interested parties, including other browser vendors. We're calling it baseline. If a feature is part of baseline, our aim is that most web teams should feel confident to just use it. It has broad cross-platform and cross-browser support. Features will only move into baseline once they are interoperable and safe to use. You'll be able to share with stakeholders that all features used in your site or app are in baseline and point them to information so they can see what that means. We'll provide clear guidance, explaining what makes something part of baseline and how we make the decisions. Our aim is that baseline can be adopted everywhere that developers go to look up information about features. On MDN, can I use in web.dev? Baseline is available to be adopted on any other site that provides tutorials or documentation for web developers. It is available to be adopted by developers of frameworks to provide a clear indication of the level of browser compatibility they have. The group of features in baseline will grow as more things become interoperable. However, it will be easy to see what has become part of baseline each month or year and therefore which new things you might feel safe to use without needing to do a lot of research. With safe features defined, we want to play our part in bringing new features to the web that can become interoperable and therefore part of the safe feature group as quickly as possible. The aim of any new web platform feature should be to become part of baseline. We've defined a set of features that we want to land and are planning their release with an aim to help get them into other engines as quickly as possible. That means working with other browsers to ensure they agree and are happy with the feature. That means doing things such as working with Igalia to land features in other engines when they are happy to include them but don't have the resources to prioritize them themselves. We're really excited about all the work we're doing alongside our partners to create a stable web. Check out web.dev for more information on everything I've covered today and see the talk by my colleague, Mariko, to learn about just some of the exciting features that are part of baseline right now. Thank you.