For users, the promise of the web is simplicity — you don’t have to install anything, just type in a URL or search. But for Developers, it’s about reach and portability — and that requires strong compatibility and interoperability between browsers.But even with Internet Explorer gone, the top frustrations that shows up in survey after survey of web developers are all about the lack of compatibility: avoiding features that don’t work in multiple browsers, making designs look and work the same way in different browsers, and testing across multiple browsers. “Making things work between browsers is their biggest pain point,” Kadir Topal, who works on the web platform at Google, told The New Stack.For the last few years the Interop project (and the Compat 2021 effort that preceded it) have helped to reduce and eventually remove a number of these compatibility pain points. But even if they know about focus areas targeted for improvement through Interop, web developers aren’t likely to keep checking the Web Platform Tests dashboards when they’re deciding what features to use on a site, let alone follow the various draft and approved stages of specifications on their sometimes slow progress through standards development, even with the W3C’s fairly comprehensive list of browser specifications.Despite the name, Chrome Platform Status covers more than one browser; but entries aren’t usually updated after a feature ships in Chrome, so you can’t rely on the compatibility details to stay current. Apple no longer publishes a WebKit status page, although you can look up its position on various proposed web standards; Mozilla keeps a similar list of its own positions on specifications, but both are mainly a glimpse of the future. Developers can check the CSS database and bug trackers for Chromium and Firefox, look up polyfills at Polyfill.io, or check on feature status on MDN and caniuse.com.Or they might just stick with what they know works already. If we don’t want to lose out on the promise of the web platform with evergreen browsers and living standards, how do we make it easier for web developers to know which web platform features are ready for mainstream use?Because different browsers are developed and updated on their own schedule, there’s no one moment when everything in a standard becomes available universally. Safari 16.4 was a major release with a long list of new features — some of which have been supported in other browsers for five or more years.Release notes might attract some attention, but if developers hear about an interesting new feature in a conference talk or a blog and look it up only to find it works in only one browser, the excitement about it can easily dissipate. Developers want to know what works everywhere, and even when features are in multiple browsers, “they’re often available with bugs and inconsistencies, and therefore developers often deem them impossible to use in production,” warned Topal, who worked on MDN for many years.What it adds up to is that while the caniuse site is invaluable, “developers are unclear on what is actually available on the platform”.Baseline is a project from the WebDX Community Group that attempts to remove that confusion, “making it really clear to developers what they can and cannot use on the web platform” by listing the set of features that are available in all the major browsers and (in future) making it easier to track new features that are under development.Rather than adding features as they get released, which could turn into just one more thing to try and keep track of, the list will be compiled once a year. “We’re hoping that once a year we can do this cut of the platform and say, ‘this is the web platform baseline 2023, 2024 or 2025’. Then each year we can talk about what’s new: what are the things that you can use now that you couldn’t use before, not just that they’ve landed in a browser, but are actually available to you because they are already widely available.”The criteria for a feature to be included in an annual baseline is actually stricter than for most web standards, which require only two implementations: baseline features have to be supported in the current and previous version of Chrome, Edge, Firefox, and Safari. “The idea of Baseline is to provide a clear signal for when something is broadly available, and shouldn’t end up causing any problems, rather than just leaving it up to developers to work it out,” explained Mozilla engineer James Graham.Baseline isn’t a return to waterfall engineering, by deciding in advance what features will be in the next year’s web platform, or an attempt to force all the browsers to coordinate the features they ship, Rick Byers, director on Google’s web platform team, noted. It just records what features are actually broadly available in browsers, in a way that’s easy to spot in documentation or highlight in a blog. “It’s breaking the assumption that the pace of developer understanding has to match the pace of standards development.”Communicating to busy developers has been the missing piece of standards development. “As browser vendors, we’ve been focusing a lot on the things that we ship in our own browsers, but for developers what really matters […] is what is it that they can use now,” Topal said. “Once features are available across browsers, and once they are interoperable, we still need to go out there and make sure that developers are aware of them. Because for the longest time we basically trained developers to look at features that land in browsers as things that they might be able to use in a decade from now.”Web standards are changing quickly and there’s still plenty of experimentation pushing it forward, but the platform is also getting less fragmented, he maintained. “Now that we have more collaboration between browsers and things are shipping faster across browsers and in a more interoperable way, we also need to change the mindset of developers that the web platform is actually moving forward.”“Baseline is one way for us to get that across in a way that’s not chaotic.”Google will be using the Baseline logo in articles and tutorials on web.dev, but perhaps more importantly it will also be on MDN and — hopefully by the end of 2023 — on caniuse. There will also be widgets that make it easy to include the Baseline status of a feature in a blog or other documentation.One of the first MDN pages to highlight the Baseline status of a feature.“We’re excited to be displaying Baseline support on relevant MDN pages. Through our research, we found web developers lack a quick and reliable way to see the status of features. And while our browser compatibility tables are useful and accurate, they are detailed and more suited to a developer’s deeper support research,” Graham noted. “It’s still early days, but we’re looking to roll it out further over the next few months. This will allow us to gain feedback from our users to make sure it’s a useful and relevant feature for them.”So far, the Baseline information is only on a few MDN pages, and not even on all of the pages documenting some recent features Google calls out as qualifying for Baseline status. Partly that’s because it takes time to add the information to MDN and the Open Web Docs project that MDN draws from, and for the caniuseteam to integrate it, but he also added, “Discussions about exactly how to decide when a feature meets the bar of being broadly available are ongoing.”“The point of Baseline is to make it clear when features are safe to use without worrying about running into bugs and compatibility issues,” he explained.There’s always a tension between making information clear enough to grasp quickly and detailed enough to be useful.The caniuse site doesn’t give developers the yes or no answer they might be looking for. But the browser landscape is equally complex and not everyone updates to the latest browsers as soon as they ship — or uses the four main browsers that will be covered by the annual Baseline feature list. A commercial website or web application may be able to dictate what browsers customers can use with it. But a government department or a service provider building a website will need to support a very wide range of users and devices, and may need to use polyfills and progressive enhancement to cover all the browsers they need features to work with.“Developers have situated needs regarding interoperability, which is why tools like caniuse are so helpful,” Alex Russell, Partner Product Manager on Microsoft Edge, cautioned. Sometimes you need the extra detail. “Caniuse allows developers to import their logs to weight feature availability to represent their user’s needs with higher fidelity than a general-purpose lowest-common-denominator view can provide.”You can pair the compatibility matrix on caniuse with usage statistics for a detailed view of where a particular feature will and won’t work — IWantToUse has a friendly interface for doing that for multiple features — but even so developers won’t always find the information they need, Graham pointed out.“In some cases, the specific APIs you’re interested in don’t directly map to something in caniuse, so you need to look at the MDN browser compatibility tables and work out for yourself whether the users you’re hoping to support are likely to have access to the feature.”That compatibility data is on individual MDN pages, so developers have to check one API at a time — or run a query against the data in the browser-compat-data repo and the W3C’s browser implementation status repo, which adds in Chrome Platform Status and caniuse data but still isn’t a comprehensive list of all web features.These different resources don’t always match up completely. BCD covers some 14,000 features — down to API interfaces and CSS properties — while caniuse has a higher level list of around 520 features and the 2,200-odd entries in Chrome Platform Status are a mix of both; but from the viewpoint of people building a browser rather than a web site, so there might be separate listings for different interfaces in an API like FileReader.“All sites are different since they have different needs and audiences, so it’s hard to pick a line that works for everyone all of the time,” he noted. Baseline may have less detail but it will also be much simpler for developers to keep track of.“The aim is that we get to a place where developers trust that if something’s in Baseline, they feel confident to go ahead and use it for any kind of website that doesn’t have really unusual compatibility requirements. And by putting it directly on MDN, we hope that developers are able to learn when features have reached that threshold of usefulness much faster than they do with the current processes.”One of the biggest advantages of the Baseline project may be the opportunity to make more web developers familiar with the cycle that moves the web platform forward — features emerging in origin trials in browsers; being tested, stabilized, standardized and made interoperable through projects like Interop, with features that score well enough on interoperability graduating into each year’s baseline.Subgrid is a good example of that pipeline. Currently, it’s not something most developers can use. “Features like subgrid that haven’t shipped everywhere — subgrid isn’t in stable Chromium even though it’s been in Gecko and WebKit for a while — are really hard to use on mainstream sites without causing problems for users,” Graham cautioned. But it’s also a focus area in Interop 2022 and continuing in 2023 to make sure it ships as an interoperable feature. “The hope is that once features ship, they’re already in a usable state and so developers are able to use them on production sites much sooner than they could in the past. This in turn should mean things reach Baseline much sooner than they might have historically.”Indeed, subgrid is now starting to ship in browsers, Topal said. “Next year it’s going to be in Baseline: it’s going to be widely available and we’re going to talk about it again because that’s when most developers, most of the time, will be able to use it.”Knowing the cycle works could encourage more developers to bring up their interoperability and compatibility issues in the open bug tracker that feeds each year’s Interop priorities.But it’s also important that a browser baseline doesn’t limit developers to only consider features that all the browsers agree on, in a way that holds the web back if some of the browser makers fall behind on features that don’t make it into the Interop focus areas. Baseline can’t be a “good enough” bar that allows browser makers to skate on delivering further progress.For all the community positivity around Interop and the advantage of having the most influential browsers involved and making commitments to fully develop and support features, the price of that involvement is that they also have a veto. And while the bug tracker and the web platform test results are public, the governance of the process for reaching consensus and committing to the focus areas each year isn’t as open.That underlines Interop’s complicated balancing act: getting browser vendors, who nearly all also have other platform interests beyond the web, to commit to moving the web platform together compatibly is an enormous achievement, but the process has to accommodate the various commercial pressures they all face to keep them involved.As well as driving improvements in web platform test scores across all the main browsers, Interop (and the web platform test suite that underlies the project) has clearly helped draw more attention to the importance of compatibility and interoperability between browsers. Last year, the HTTP Archive’s Web Almanac included a section on interoperability for the first time, and Baseline is a continuation of this new focus.But arguably, the reason we’re now seeing much faster progress in browsers like Safari (where Apple has hired a much larger team in recent years and is updating the browser far more frequently) is due not just to Interop providing a way for browser makers to jointly set priorities for improving compatibility, but also to the impact of regulators (like the UK’s CMA and the Japanese equivalent) investigating competition in mobile ecosystems and what part browsers play in that.In the end, the continuing success of Interop likely depends on correspondingly continuing pressure from web users, developers and regulators demanding a web platform that is powerful and compatible. Broader participation in Interop, perhaps driven by developer awareness as part of the Baseline project, could help. “The thing that I would like to happen next time for Interop 2024 is for more people to know about the process,” Daniel Ehrenberg, vice president of Ecma (parent organization of the TC39 committee that standardizes JavaScript) told The New Stack.Alongside Baseline, the WebDX group is also involved in research like the State of CSS and State of JS surveys, along with short surveys on MDN: “They’re really quick to fill out, and limited in scope, so that we can get input from people who don’t necessarily have the time to spend on a longer form feedback process,” Graham explained.All that will feed forward into Interop 2024 by identifying the things on the web platform that need acceleration, Topal suggested.“Instead of ad hoc asking about things that we could do in Interop, what we want to get to is a shared understanding of developer pain points between browser vendors. Even though we all already have individual product strategies, we’re still addressing the same audience. It’s the same web developers. We want to get on the same page since we own this platform together, we maintain this platform together. We want to make sure that we together have a shared understanding of the developer pain points.”What’s also interesting about Baseline is that like async context and Open UI, it’s emerging from a W3C community group rather than a standards body.Since the days of HTML5, the WHATWG, W3C and (to a lesser extent) ECMAScript approach of “paving the cowpath” by codifying the most common patterns found on websites in the standards for browsers has meant that standards often reflect patterns adopted because browsers already support them.Open UI and WinterCG incubate draft proposals that are brought to those standards bodies for consideration, aligning more with the Origin Trials that Chrome and Edge use for features they want to bring to the web that solicits developer feedback and produce tests and specifications.Separating design from standardization like this can have the advantage of working faster — and failing faster — than a formal standard process, with a tighter feedback loop with the developers who are interested in a new feature. Iteration and experimentation in a community group can preserve momentum even when ideas don’t work out the first time. It also avoids everyone getting stuck with the first implementation of a feature when that turns out to have design flaws that can’t be changed because developers have already taken dependencies on them.The Web DirectX community group includes not just Interop participants Apple, Google, Microsoft and Mozilla, along with Igalia and Boucoup, but organizations like LG who aren’t as well known for making a browser. “It’s a new era of collaboration on the web platform,” Byers suggested.Having Baseline emerge from a community focused on developer experience should help it become something that’s useful for developers, rather than something that lets web browser makers pat themselves on the back for how well they’re doing, and likely means we’ll see iterations in the way the annual Baseline is decided on and what it includes over time. If it takes off, it could add another level to the way the web platform creates and adopts the standards that make it powerful.Community created roadmaps, articles, resources and journeys fordevelopers to help you choose your path and grow in your career.