“It’s in society’s interest as a whole when Browser vendors feel the need to be interoperable.”Government regulation on competition is one part of pushing that interoperability forward; the Interop project is another key part, Rick Byers, director of Google’s web platform team, told The New Stack. Last year Interop 2022 delivered significant improvements in all four main browsers. This time around, it’s not just about getting individual browsers to make feature implementations more compatible with the same feature in other browsers, but about measuring how well all the browsers deliver the same web platform.For browser makers, the need to allocate development resources can make it feel like there’s a tension between adding new features to the web platform and going back to fix interoperability issues in features that have already been shipped. Interop focuses on technology that is already specified in web standards with shared test suites in web-platform-tests (WPT), but it covers a mix of features that have already shipped (in some or all browsers) and features that are still being implemented — some rather belatedly.Interop is open to any organization implementing the web platform, but since it’s about having web platform technologies work the same way across multiple browsers, it’s run by the four major browser implementers and two open source consultancies who do a lot of work on the web platform: Apple, Google, Microsoft, Mozilla, Bocoup and Igalia.Interop progress as of August 2023.“It’s really good that there’s companies out there that realize that the web standard process is not only for people that build a browser and want to show ads, but that everybody benefits from it, because we can write more secure and stable applications if the platform gives us solutions that we don’t have to simulate [in JavaScript],” explained developer advocate Christian Heilmann — who used to work on the Firefox and Edge browser teams.For instance, he pointed out, before the dialog element was supported across browsers, every developer had to build their own with a positioned div element, write the JavaScript code to show and hide the dialog — and usually with tweaks for different browsers. It might sound like a trivial example, but that’s a lot of unnecessary work repeated on every project.Browser makers could (and do) fix interoperability and compatibility issues individually using WPT, but the value of Interop is that it makes for more coordination of what all the browsers work on each year by focusing on what developers are seeing problems with. Those developer pain points are gathered through the surveys that MDN runs — both the big annual State of CSS and State of JS research projects and, in future, shorter regular surveys on MDN — and a bug tracker for issues submitted via GitHub, then turned into formal proposals for the Interop participants to vote on in November 2022.This time around, that generated a lot of requests and suggestions, Igalia developer advocate Brian Kardell told us. “Last year, we weren’t very proactive. We had a wider call for this year, and we left it open a little longer and we had, at peak, maybe 90 different issues open.”“Interop 2023 is the biggest, most aggressive attempt at interop I think we’ve ever made.” — Rick Byers, director of Google’s web platform teamThere are 26 focus areas, compared to 15 in 2022 (eight of which have been carried forward from previous years), plus several investigations — where there is work to be done but the standard or the web platform tests aren’t mature enough to start implementing. “Among those focus areas are some things that developers have asked us for forever.”The 26 areas all the browsers agreed to work on range from features everyone uses on the web without realizing, to those last annoying paper cuts in otherwise finished areas.The point of Interop is often getting multiple browsers to the same stage. Firefox has supported multicolor forms for a long time; the vector color font support that’s part of Font feature detection and palettes brings that to all the main browsers.Browser progress chartOn the other hand, Firefox lagged on Modules in Web Workers. “Right now, Web Workers don’t allow me to use other people’s JavaScript modules. I can send data in and get data out: I cannot have any interaction in between [anything with third-party dependencies],” Heilmann explained. “Web Workers become more important as we do more high-performance stuff in the background, especially with machine learning: you don’t want that on the main thread.”That’s already improved since Interop 2023 began, as has Firefox support for Color Spaces and Functions, going from passing just over half the tests to almost 95%. That means designers can specify uniform gradients and color shifts so sites look the same in different browsers and on screens with different color gamuts, and developers can lighten or darken colors in CSS without having to recompute them. Operating systems are already beginning to support better color formats and if the web platform follows, “this world of more colorful, rich vibrant things becomes possible,” Kardell explained.Similarly, at the beginning of 2023, Safari had much better support for Math Functions, which let developers do things in CSS (like tracking mouse cursor position) that used to need Canvas or precompilers: now all three browsers score in the high 90s. Chromium browsers started the year with less support for Masking in CSS: applying the kind of image effects you’d use in a graphics application to a web page, like using an image or a gradient to mask or clip an image. Again, doing that in CSS avoids the need to use canvas for something that helps web apps feel more native on different platforms. Animating a graphic along a custom motion path with CSS is supported in all three browser engines, but doesn’t work quite the same way in all of them.Many focus areas improve developer productivity, like being able to rely on the border-image CSS property in all browsers for replacing the default border style “with one element rather than five nested elements just to get a frame around something,” Heilmann said. And some go back to basics: URL is about getting all browsers to agree on an implementation of URLs that matches what’s defined in the standard.“It’s quite amazing how many things are a valid URL and how dangerous that could be.” — Christian HeilmannDrawing graphics on the screen with the canvas element and API lets you script graphics, but running that on the main browser thread can block anything else a user is trying to do on the page. Offscreen canvas, as the name suggests, puts that offscreen where it won’t interfere with rendering handled in a Web Worker. It’s widely used in game development, Heilmann explained: “We [always] had one canvas that showed the game and we had one canvas that did all the calculations; and that way, the performance was so much better. Standardizing that rather than having to hack it every single time would be a really, really good thing.”It’s not just a specialized technique though; most web developers use offscreen canvas already but without realizing it, because they use it through a library, Kardell pointed out. “A very small number of libraries need to update to take advantage of that and then suddenly, everybody in all the places that they’re using it will get better performance on maps and drawing tools and Figma and all kinds of cool stuff.”Custom properties (or custom variables) is another long-standing request, that will make it much easier to use CSS variables — for example, defining colors, font sizes and other settings once, directly in your CSS, rather than putting them in a selection block, which will simplify switching a site between light and dark mode. This focus area is concentrating on @property, which lets you set default and fallback values when you define a custom property in a stylesheet; again, this isn’t new, but it hasn’t been consistent between browsers.CSS Pseudo-classes add a keyword to specify a special state, like the way a button looks when you hover over it, so you can style it. That will be useful for input, but also media handling for full screen, modal and picture-in-picture; and interoperability is particularly important here, Heilmann noted. “We need to actually make sure that every browser does them the same, because if we have yet another one that is only in Chrome it costs us a lot of time and effort.”Isolating part of the page with Containment in CSS, so it can be rendered independently, whether that’s a navigation bar or an animation, is “very good for performance” Heilmann said. Although it can be somewhat complex to work, because it requires some understanding of rendering and layers, he suggested most developers will use it through tools like GreenSock rather than directly.Other focus areas include substantial work on long-standing web developer priorities that will be widely used. “has() and Container queries are literally the number one and number two requests for a decade from web developers and we’re getting both,” Kardell enthused.“Container queries is a CSS mechanism to reason locally about layout decisions,” Byers explained: “To understand the context, the container you’re in, and do responsive design in a way that works well across components, so you can build more reusable components that work in whatever layout environment they’re put into.”If you put a component in a container that doesn’t have as much space, you could pick which elements should be hidden, or just switch everything to a smaller font.“This is a direct answer to the needs of the componentized web for something like reusable components to put together bigger applications,” Heilmann told us.To Byers, it also highlights the opportunity Interop gives developers to highlight what they need.“Just a couple years ago, most of the browser engines were saying, ‘we don’t think this can be a feature, we don’t think this is something we can put in our engines’. And now not only does it exist in Chromium and WebKit, and it’s coming in Gecko, but it’s something all three of the major engines believe — that by the end of the year we can have working interoperability and stability and something you can actually depend on. For web developers, that should be enormously exciting, not just because that feature is exciting to them, but because it signals this is the kind of thing that web developers can get done on the web. When they come together and push and say, ‘Hey, this is a capability we really want in the web’.”Similarly, the idea of having a parent selector (has) to go with the child selector has been in the CSS spec since the first draft of CSS 3 in 1999. Heilmann suggested thinking of it more as a family selector: “It can allow you to look around you in the DOM in each direction, which we couldn’t do with CSS before, and I think that’s a huge step towards people not having to use JavaScript to do some things.” That would make it easy to have one style for an image that has a caption and a different style for pictures that don’t.Like container queries, the implementation was held up by worries about slowing down page loading (because the rendering engine might have to go up and down the DOM tree multiple times to apply a developer’s CSS rules correctly).“Performance has always been the barrier, because of the way pages are assembled and because of the way CSS and rendering engines have been optimized in browsers,” explained Igalia web standards advocate Eric Meyer, who built one of the earliest CSS test suites. “When we lay out a page, we generally do one pass: we do not want to have to do multi-pass [rendering] because that’s a performance killer.” Two decades on, computers are faster than when has() was first proposed, but “you could still grind a browser to a halt with container queries or the ‘parent’ selector”.“It’s a scary thing that no one wants to take up because it’s computationally complex, and it could just really blow up performance,” Kardell added. Years of discussions about these features might have helped make them seem impossible, he suggested.“When you have things that have been discussed a lot, that seem hard, that look like you could invest a lot of money and a lot of time and it might not go anywhere — it’s unsurprising that nobody wants to break the standoff!” — Brian Kardell, IgaliaIn the end, investigation and experimentation by multiple browser teams (and a bottom-up approach suggested by Igalia) showed that these features could work without degrading performance, including compromises to avoid the risk of circular dependencies and undefined behavior.Some of that relied-on work was done in a previous iteration of Interop, explained Kadir Topal, who works on the web platform at Google, highlighting a new pattern in browser development that’s emerging from the collaborative approach to compatibility. “Since all the browsers shipped that [work], there was something that we could build on top of. I think we’re going to see more and more of that, where we can ship together something in one year, and then build on top of that in the next year. I can already see some of that coming for the next year.”The technical work is critical for unblocking implementations that give developers what Byers considers “most of what they were asking for” with container queries, but he also noted that this is also part of a different philosophy in building the web platform that’s not just about what browser engines need.“The larger story for me is the shifting of how we approach platform design to just be more humble and listening to developers more. Browser engineers used to say ‘anything that can introduce cycles and delays sounds really scary, so like I refuse to go there on principle. Over the last several years, I think the industry as a whole, but certainly the Chrome team, has really had this transformation of saying our number one job is to serve developers and really listen and really be empathetic to their pain points. We’re hearing consistently that developers are having problems with this sort of thing. It’s a legitimate problem. What are we going to do about it rather than just say it’s not possible?”Some focus areas continue from previous years: CSS subgrid has now landed in the experimental version of Chromium, using code contributed by Microsoft. Before Interop 2022, only Firefox supported subgrid; Safari added it in 2022 and now it’s going to be broadly available — and interoperable.Byers compared that to Flexbox, which had been in browsers for years “but it was just so different in different engines for so long, and there were paper cuts all over the place that we’re still cleaning up from. The way grid has happened; as much as we wish some of it would have gone faster, I think it’s the model for how big new things can get added to the web in a way that’s high quality and consistent across browsers, and not that far off timewise from each other in the different engines.”Flexbox scores are already in the 90s for all the browsers, although polishing off the last bugs takes time.“When you look at the numbers [for some focus areas], there’s almost a question of ‘why are they in Interop?’” Meyer noted. “That seems really interoperable, how come that’s there?” For example, the stable and experimental numbers for Media Queries were already high.“That actually points to one of the things that Interop was intended to do: in some cases where things are almost but not quite universal, let’s get them there. There’s just a few bugs across the various browsers that keep us from being 100% across-the-board compatible, so let’s get there.”With such high scores, he explained, browsers might be tempted to prioritize areas like Web Codecs, where Safari was only scoring 59% at the beginning of 2023, over Media Queries with 99% compatibility. “It would be very easy to say that one percent isn’t worth devoting time to when we have these other areas that really need to be dealt with. Interop is a way of drawing people back to say ‘Hey, we really do need to correct this’.”In the case of Media Queries, the holdup is Firefox with a score that’s now gone from 82.7% at the beginning of the year to 99% already (and 99.9% in nightly builds). “They really only need to fix whatever that percent tests, and Interop is meant to encourage that.”One of the most interesting charts in WPT has always been the number of tests that fail in just one browser, neatly illustrating the compatibility failures that can bite developers. This year Interop is highlighting the inverse of that: the number of tests that are passing in all the engines (Blink, Gecko and WebKit). That’s more important than any one browser having a higher score, Byers said. “It’s not about who wins: I want developers to win by that line getting as high as we can make it.“It’s the only number that really matters,” Kardell suggested. Browsers can score in the 80s or even the high 90s individually, but the Interop score for the focus area might be much lower. “By old standards, that’s off to a pretty good start, but if it turns out that each of them did a completely different 80%, then that’s not the case in any way.”While Chromium browsers are slowly improving scores for CSS Masking (from 65.8% at the beginning of the year to 69.1% in experimental builds at the time of writing), the Interop score for this focus area is improving faster — from 56.7% to 64.3% — because the work in Chromium is happening at the same time as Firefox and Safari investing further in an area where they were already scoring in the 80s.Another good example is pointer and mouse events, where the lowest individual score was 46.6% with other browsers achieving 67% and even 80%. “Looking at the individual browser numbers, you might think, well, the worst one is almost half support,” Meyer warned. “But if you create a Venn diagram and in the middle is what they all support consistently, where the three overlap is only a third [of the standard].”While that 33.3% has improved to 61.3% in experimental browser builds (at the time of writing), this Interop focus area doesn’t cover using touch or a pen with pointer-events — which is important on tablets and phones.There are lot of IP challenges and patent issues in this area and a messy history (when Microsoft first proposed pointer events, Apple suggested its patents on touch events might block the W3C from adopting it as a standard, and Apple’s resistance to supporting pointer events led to Google planning to remove it from Chrome at one point). But while that explains the significant differences between browsers in this focus area, vendor politics isn’t behind leaving out touch and pen: it’s a more prosaic problem that WPT doesn’t include the tests to cover it, explained Byers (who did a lot of the early work on touch and pointer events and was an editor on the spec until recently).“A lot of the time [when] things don’t make it into Interop, it’s because the specs aren’t ready or we don’t have tests we can push for conformance.” — Rick Byers“We have to do a lot of work to pay back the debt of not having touch input well tested,” continued Byers. “And sometimes there’s infrastructure issues like, does WebDriver support simulated touch input on all the major browsers? If not, then we can’t realistically push for common touch behavior across all browsers. We need to do this groundwork first.”“There’s almost certainly challenges around actually even validating that touch behaves consistently across a Windows computer running Firefox and an iPhone running Safari, and all those different devices. Safari doesn’t support touch on desktop; generally, MacBooks don’t have touchscreens.” Even getting the infrastructure to run the tests will be tricky: “We can get desktops in the cloud to run our tests: it’s just harder to do that for mobile.”Mobile testing is actually one of the active investigation areas in Interop 2023, because it’s currently not part of WPT’s CI infrastructure, and Topal indicated there would be more investment there in the second half of this year. Investigation areas often lay the groundwork for future focus areas. “Mobile testing as part of the Interop dashboards and scoring is something that we’ll hopefully be able to do next year,” he confirmed.Between September and November this year, the Interop participants will look at what needs to go into the focus areas for 2024, and that includes assessing progress on Interop 2023. “That’s where the decision gets made on which of the features are now basically interoperable and where there are things we [still] need to keep track of,” Topal explained.The Web Compatible focus area covers what Byers referred to as “a little grab bag of paper cuts” for “little niggly things that wouldn’t make sense on their own” but didn’t need to be an entire focus area. Some of these were focus areas in previous years: the work isn’t finished, but enough progress has been made that there are only a few issues to clean up.That’s not just about going the last mile in developer experience, important as that is; there’s a bigger point about the continuous nature of web standards, Kardell pointed out.“Interop is a strange project because it seems like it shouldn’t exist, because the point of web standards is that they’re standards.” — Brian KardellBut even when browsers score 100% on these tests, it doesn’t mean that interoperability is done, especially for areas like viewport, which needs to support new classes of hardware as they come out, like folding phones, so the focus area was carried forward even though all the work that was agreed on last year got done. “There will be test cases that we haven’t thought of. There will be places where you still wind up getting a different result. The thing with standards is eventual consistency increasing interoperability, that is hopefully stable.”As Topal noted: “It’s a living platform: it keeps getting developed, it keeps getting extended.”That doesn’t mean the Interop list will just keep getting longer. “Everything we had in 2021 is still in the list somewhere,” Byers noted. “I’m not aware off the top of my head of an area that has reached 100% of all tests passed across the board. But whatever the numbers are, if it feels that [tracking an area] isn’t providing value to developers anymore, there’s no sense in us tracking it [in Interop].The Interop project is ultimately pragmatic. “What makes it into Interop are things that browser makers either are already working on or are about to work on,” Meyer explained. “Things that any browser maker has no intention whatsoever of working on, [they] don’t make it.”MathML hasn’t been included in Interop because at least one of the browser makers objected to it and the group accepts vetoes. “If anyone puts in an objection, even if everyone else thinks it should be in there, it doesn’t go in unless you can convince the objector to rescind their objection.”Those vetoes are usually about resources and priorities. “Whoever was objecting, would say something like ‘this is really cool, and we would love to work on it, but we can’t work on this and all these other things’.” That’s not an objection to the technology: it might be about a specification that’s not yet complete. “There’s no sense [in] us adding this to Interop when the specification might change halfway through the year and invalidate everyone’s work. Let’s wait until the spec is ready and then maybe next year, we can add it.”That’s a realistic approach that underlines that the browser makers are serious about Interop, he suggested. “It’s nice to see browser teams saying ‘We have to set priorities’. They were actually thinking through ‘can we do these things’ instead of ‘sure, put it on the list and if we get to it, great’. There was none of that.”“Our goal here is to prioritize what we think is the meaningful work that we just have to get done,” Kardell agreed.The focus areas in Interop 2023 continue to concentrate on CSS, although they include JavaScript elements like Web Components and the catchall Web Compat category, which includes areas like regex look behind.Partly that’s because there weren’t many submissions for JavaScript incompatibilities, Kardell told us (which may be a testament to the ECMAScript process).But he also noted that while the web platform tests include some JavaScript tests, they don’t yet incorporate the ECMAScript Test262 test suite (new features can’t become part of ECMAScript without submitting tests to this suite), so tracking JavaScript focus areas would require doing that integration work. Some investigation has been done on how to keep the different test suites in sync, “but I don’t think we’re there yet” he suggested.“[Web standards] are constantly a learning process,” Kardell said, pointing out that for many years those standards didn’t even include formal test suites that went beyond individual browsers.“Our idea of how we manage all this is slowly evolving and we’re learning and figuring it out better.”Community created roadmaps, articles, resources and journeys fordevelopers to help you choose your path and grow in your career.