 Hello, I'm Rachel Andrew, a technical writer on the Chrome team and I'm here to talk to you about how we are trying to make it easier to build for the web. When we talk to developers informally or via surveys, we hear the same thing over and over again. Making websites work well across browsers is hard. Knowing when it's safe to use new features is hard. This slide shows the results of the 2021 State of CSS survey with browser compatibility top of the list. Interoperability, meaning the support of features across browsers, was also cited as the biggest barrier to adopting technology in the Mozilla DNA report. And in research conducted by Google, making a design or experience work the same across browsers is consistently listed as a top challenge for web developers. Here's an example. The Gap property lets you make even gaps between grid and flex items or columns in a multicoll container. It first appeared in CSS Grid Layout, initially named Grid Gap with longhand properties of Grid Row Gap and Grid Column Gap. Just after Grid Layout landed in browsers, the decision was made to rename the property so it could be used more generally in other layout methods. It became Gap along with Row Gap and Column Gap. This means we don't need to have duplicate properties such as FlexRow Gap and instead can use one set of properties for gaps between things in layouts. It was then specified to work with Flexbox. And in October 2018, Firefox shipped the Gap property in FlexLayouts. In July 2020, Chrome shipped it. In April 2021, Safari shipped it. So we had a gap of two years and six months before we had the Gap property in Flexbox in all evergreen browsers. Okay, but we've got progressive enhancement and feature queries. We can at least use margins for older browsers and Gap where it's supported, right? Sadly not in this case. Because the Gap property is supported in Grid, testing for at supports Gap returns true. Feature queries are pretty simple. They just check to see if the browser can parse that property and value if it means something to it. So there's no way to test for Gap 1M in FlexLayout. Therefore, this partial implementation meant that developers had to wait for over two years after it lands in Firefox. A gap of over two years to use a straightforward feature that would have cleaned up their code and made CSS more intuitive. This is just one example of the problem. We see this fragmentation of support again and again with different browsers taking the lead in landing something and then a gap of months to years before it lands in the other browsers. To add to this problem, as soon as Gap became available to all in Flexbox, folks like me started making demos and talking about this feature and this was a bit confusing for people who tried the demos and found it didn't work in their browser. They could then go look, check, can I use a MDM? But it's all extra work and takes time. It's frustrating to get excited about something and then find that you can't really use it, especially when this pattern keeps repeating. So why does this happen? Why do features seem to take so long to become usable? Most developers have been frustrated by this situation at one time or another. It might not have been Gap, but unless you've been very lucky there will be at least one feature you've wanted to use and then you discover it didn't work or work differently in one browser. New platform features come from a variety of sources, but often the initial idea and prototyping is done by one browser vendor. For example, the initial grid layout spec was created by Microsoft and implemented in an initial form in Internet Explorer 10. An engineer at Mozilla did a lot of the work to figure out how the subgrid feature for grid layout should work and so subgrid landed in Firefox first as they'd already done this work. The container queries feature is being prototyped in Chrome. Different browsers take the lead on different features and so the feature is likely to show up there first. This prototyping work is done in collaboration with people from other browsers. For CSS, that's through the CSS working group. It's very important that a feature can be implemented across all browsers and isn't designed in such a way that it would be impossible for another browser to add the feature. That would lead to a permanent gap in support which no one wants to happen. There's no benefit to any browser to have a feature that isn't supported across all browsers because web developers won't fully adopt it. However, when it comes to doing that implementation work in the other browsers, a feature has to be prioritized. Browsers are just like any other product. There are many features that could be added and so the business has to figure out which ones to do first. Sometimes internal changes might need to be made to make a feature possible. A good example of this is the rendering NG work. This rewrite of the rendering architecture fixed a huge number of bugs but features like subgrid were held up behind it, waiting for grid to be implemented in the new architecture. For most developers, the time a new feature is considered safe to use. It's once it's landed in the three major browser engines, Chrome, Firefox and Safari. Yet what we tend to see is a timeline like this. We get a lot of noise about a thing at a point where it isn't usable and sometimes very little announcement when it actually lands everywhere. By that point, it's old news and the developer influencers have moved on to the next shiny thing. There are two issues here. Firstly, the interoperability problem, the fact that features take a long time to be usable cross browser. This might be because the feature hasn't yet been implemented or has been implemented in a buggy or inconsistent way. The second issue is that of confusing messaging. Blog posts, videos and tutorials all appear at a point when the new thing is actually unavailable to most developers. It can appear that a thing is ready to use when it's not leading to wasted time and effort. So what can we do to fix these issues? The first issue is one that browser vendors are uniquely positioned to solve. If vendors place a priority on reducing fragmentation, by reducing the time it takes for APIs and features to ship, we can bring the time down from the first to the last browser to land a feature. By working together, browsers can ensure that bugs and features that prevent them from being useful are solved quickly. And this collaboration is already happening. The web platform test project is a cross browser test suite for the web platform. Tests are written in a way that ensures they can run in all browsers. They let browser engineers know that their implementations are compatible with other implementations as they work on a feature. They help to prevent regressions, where a previously working feature develops a bug due to some change in the browser. However, not all fragmentation is equal. Some bugs are of a much higher priority to developers and may even stop them using a feature at all. So we've been working to prioritize these fixes. The compact 2021 project focused on five areas where differences between browsers were causing problems to developers. Flexbox, grid, position sticky aspect ratio and transforms. Over the course of 2021 interoperability bugs were fixed in all these areas by all browsers. For example, flex basis content, which was implemented in Firefox is now also implemented in Chrome and WebKit. Firefox fixed a percentage height bug in Flexbox. The Edge team at Microsoft led work on the CSS grid through the GridNG project, which launched in Chrome 93. This was part of the rendering ng work I mentioned earlier. This increased the compact 2021 score for grid in Chromium from 3% to 97%. And as part of this work gap landed in Safari, making it available to us to use cross browser. So this project helped to fix a bunch of annoying issues in the platform and all vendors were keen to do more. And so earlier this year interop 2022 was launched. This time the selection and prioritization of features was made by representatives of all browsers and third parties who involved the platform. This robust prioritization effort resulted in 15 areas, the existing five from compact 2021 plus 10 new ones. These new areas of focus are those which are most troublesome for developers when building for the web. Cascade layers, CSS color spaces and functions, new viewport units, scrolling, subgrid, the contain property, the dialogue element, form controls, typography and encodings, web compact issues. This effort also includes three areas of investigation, places that we no need improvement, but where the current state of specifications or tests is not yet good enough to be able to score progress. And these are editing pointer and mouse events and viewport measurements. By working together, we can hopefully work out what should be done in these areas and ensure they have good specifications and tests and improvements can be implemented. Work is already happening in all of these areas and you can follow along using the interop 2022 dashboard. So what about the second issue? The fact it isn't always clear to developers whether a feature is usable yet when looking at developer news and resources. There's always a temptation to talk about the new exciting shiny thing and there's a place for that. Many of you like to know what's coming and also enjoy getting involved by testing new features and reporting bugs. However, we feel it's important that you know when looking at our resources what the real status of a feature is. And we're working to make sure that the resources you see from the Chrome team are clear in that regard. On web.dev we've launched a number of fundamental courses with more to come showing you how to use core web platform technologies. We're identifying the places where we can provide solid cross browse information to help you build great websites and applications. Be that in terms of performance, accessibility or beautiful and usable UX. We're also contributing to web documentation through our support of the Open WebDocs project. This project is ensuring that we have first class documentation on MDN along with up to date browser compatibility data. We even use that data in our web.dev articles showing the browser status of features we write about. We're trying to be clearer when something is experimental in Chrome, currently only available in Chrome and when it's ready for you to use because it's supported everywhere. So the good news is that we're working to make things better. The Flexbox gap feature is now something that's safe for you to use. It's available in all evergreen browsers. We hope that by the end of this year, you'll be seeing an improvement in all of these areas we're focusing on along with our colleagues at the other browsers through the Interop 2022 project. And because there will always be something of a gap, even if it's a smaller one, we're working to ensure that our messaging is clear when we talk about features. We want you to enjoy building for the web, to have fewer frustrations. So our aim is to do our best to fix the gaps and to be clear and honest with you about the places where they still exist. We're starting with our own sites, publishing content on web.dev that is browser agnostic, that you should feel confident is well supported and current best practice to help you build sites today. On Chrome developers, you'll find more of our vision for the web, the things we're experimenting with in origin and developer trials, and information about changes to Chrome that will help you plan. And do talk to us and let us know what you think of the content we publish, and of efforts such as Interop 2022. You can keep up to date about our newsletter and talk to us about the Chrome developers Twitter account. Thank you for watching and being part of IO. I hope you're now excited to see how much better we can make web development by bridging the gap this year.