Browser Vendors Aim to Heal Developer Pain with Interop 2022

The web is supposed to be a platform where multiple implementations deliver the same standards: there’s a new emphasis on having browsers actually deliver that interoperability.

Interoperability has always been the promise and the frustration of the web, but getting different browsers to do the same thing remains onerous for many web developers. Given that W3C, TC39 and other web standards processes all require implementations in multiple browsers and engines before a proposal can become a standard, you might expect all browsers to behave in the same way for features that are based on web standards. In practice, given those browsers are built by different vendors and they have to run on different devices where not everything will work the same, behaviors can be frustratingly different.

Web developers regularly call compatibility and interoperability issues between browsers their top frustration in surveys like the MDN Developer Needs Assessment (explore the data from those studies in the Browser Compat Data repo).

The MDN survey results show how frustrated developers are with browser compatibility issues.

Interop 2022 is part of an ongoing project to make that less painful for all web developers: “how do we reduce the number of web developer tears per second in the world,” asks Philip Jägenstedt, a software engineer on the web platform team inside Google — and he’s only partly joking.

Web of Pain

Take the developer at Google described by Rick Byers, director of Google’s web platform team, as “one of our biggest proponents of the web platform”. That person’s feedback when they moved to work on Gmail for iOS instead of the web version: “it sure feels nice to not feel like I’m fighting the platform all the time anymore”.

That kind of reaction came as a surprise to people building browsers, because as Alex Russell (a former colleague of Byers and now working on the web platform at Microsoft) pointed out at the Polymer Summit back in 2017, “browser engineers tend not to viscerally feel the problems that we feel as web developers.”

Developers care less about standards in the abstract, Igalia developer advocate Brian Kardell notes: “They want to know am I going to experience pain if I try to use this?”

“Whatever you think that you want as a developer, the first thing that you want is for all the sites to actually work the same.”

Instead, they would experience interoperability problems in features as widely used as Flexbox. “Flexbox has been around for a really, really long time and people use it all the time,” said Kardell, who estimates that 70% of sites on the HTTP Archive use Flexbox and that there were a thousand bugs to fix.

The “last mile” work of running tests and fixing bugs to get perfect interoperability isn’t exactly exciting and it takes a lot of effort, he noted. “It’s really hard to operate with perfect interoperability with varying architectures across varying operating systems.”

Taking Tests Seriously

Byers blames much of the frustration developers have experienced building on the web on how browser makers had, naturally enough, focused on their own browsers rather than the web itself. “Our job on the Chrome team is not to build Chrome. Our job is to help the larger community build the web.”

Changing that priority made it clearer how to improve the web developer experience. “We need to really approach the web platform with the engineering discipline it deserves if we want developers to take it seriously as a serious platform.”

“It should be no surprise that developers are frustrated. The web behaves inconsistently. We have applied none of our engineering expertise. Step one in software engineering is you should have a coherent test suite if you want reliability: the web didn’t have a coherent test suite.”

Tests suites for browsers did exist, Jägenstedt is quick to point out. “The problem was we didn’t care very much about it.”

Too often, the testing happened after features had been shipped and often it was outsourced.

Once the Chrome team realized that they did indeed care about web platform tests and announced a session on the predictability of the web at BlinkOn, representatives of other browsers who had been advocating for tests approached them enthusiastically, Byers remembers.

“We didn’t have to push a big rock up a hill, we just had to say we’re going to take this seriously and the entire community came together in a really positive and constructive way to say well, of course, this is the right way to engineer things. We’re all engineers at heart, clearly, we’ve been just dropping the ball on engineering. Let’s get together and work together as a community on really engineering the web with a common test suite that’s a first-class citizen.”

The community created conference sessions, mailing lists, dashboards and bug trackers focused on interoperability: things Jägenstedt describes as “trying different things to see what’s going to work to give us all incentives to improve the web platform for web developers”. One of those was the Compat 2021 project (later renamed to Interop 2021) that Google, Igalia and Microsoft collaborated on, covering five specific areas highlighted in the MDN surveys and Mozilla’s very comprehensive Browser Compatibility Report as particular problems for developers: Aspect Ratio, Flexbox, Grid, Sticky Positioning and Transforms.

The idea was to fix problems where there’s a standard that’s clearly specified and widely accepted enough to have multiple implementations, but those implementations have bugs — or are just incomplete.

The MDN browser compatibility report shows some very specific frustrations.

“We picked some areas that seemed to be problematic based on our understanding of the web developer pain points,” he explains. For each of those, they looked at the specifications and relevant tests to come up with a metric to track how well the different browser implementations do.

Participation and Priorities 

Interop 2022 brings together more participants — adding Apple and Mozilla, as well as Bocoup (a consulting cooperative with a particular focus on accessibility and inclusion) — and again, the focus is on features that improve web developers’ lives, where the technology is mature and the impact clear, rather than trying to tackle everything in Web Platform Tests (which covers standards and proposals that are at many different stages of development, or even experimentation).

As Brent Fulgham, who heads up the WebKit web compatibility team at Apple, put it in a tweet, “Interop 2022 represents the technologies that we (web engine maintainers, standards bodies, and web developers) targeted as the most important metrics for good web compatibility and interoperability.”

A spokesperson from Microsoft told us that Interop 2022 is about “ensuring that web developers can rely on those standards and deliver innovative experiences to their customers”.

The Interop project is about participation and mutual consensus on shared interests, Google’s Jägenstedt emphasized. “We recognize that we can’t force each other to do things we don’t want to. This is not an effort to make Mozilla implement a thing that we like, but they don’t; that was off the table.”

“We didn’t try to negotiate a shared list of priorities. We just came together and looked at what could we agree to; and if someone didn’t want to say, why that wasn’t a part of the process.”

“What are the things that we can all mutually agree to that are important that we’ll focus on together? These are things that we all want to invest in and we can do it so much better if we do it at the same time and in collaboration. It’s a win-win situation.”

Rather than simply good intentions about improving interoperability, Interop is measurable: again, it has metrics generated by automated tests, making it clear how much work needs to be done and how much progress has been made. The scores on the Interop dashboard are calculated by weighting the 2022 and 2021 priorities, which reflect technologies that developers clearly want to use. “We wanted to make sure that this is measuring the real-world interoperability of the feature,” he notes.

But the metrics also mean the work is effectively being done in public. Picking the focus areas meant deciding “is this strong enough that we want to, if not quite commit to doing the engineering work, but be willing to have this metric out in public that’s going to make us look bad if we don’t do the work.”

Working on interoperability in a coordinated way means not only do all the browsers improve but they improve together.

10 New Focus Areas for 2022

As well as proposals collected from developers through the Web Platform Tests repo and bug reports from end users, that turn out to be about implementation differences between browsers, Jägenstedt says the State of CSS study played a big part in picking the ten new focus areas for 2022 “because that’s where we had the most and the best data”.

The full list is Cascade Layers, Color Spaces and Functions, Containment (which is a first step to addressing the Container Queries support many developers have been asking for), Dialog Element, Form Fixes (like the work Open UI is doing on making forms work the same way across browsers), Scrolling, Subgrid, Typography and Encodings, Viewport Units and Web Compat (not a specific feature or technology, but a catchall for known problems with various features that have already shipped in the various browsers, but that have bugs or mismatches with the standards that stop sites working the way they’re designed to).

“It’s a mix of both fixing the old things that are slightly broken and also some more forward-looking things where we nevertheless had some implementation experience. We’re not writing new standards here, we’re not doing totally greenfield things,” said Jägenstedt. “All the things that we’ve prioritized are things that had some implementation experience at the beginning of the year that we think can benefit from accelerating and making them available everywhere.”

“There were some things that each of us considered important that maybe didn’t make the cut where we did need to do more work before we can get there. What we were left with was a set of things that, if I may say so, I think is going to make developers rather happy when it is available everywhere.”

For example, CSS Subgrid is already in Firefox, making it easier to line up objects in complex grid layouts; Safari has implemented support over the course of 2022, and it’s coming “pretty soon” to Chrome and shipping Subgrid in Edge (which is based on Chromium) is what Microsoft is primarily focusing on as part of its Interop 2022 work.

Viewport units are another great example of how much of a difference adding a focus area to Interop can make. Developers complain about viewport units repeatedly in the Browser Compatibility Report and the CSS Survey, because they don’t work well on mobile, where you have to allow for the address bar and the way the size of the browser’s viewport changes as you scroll through the page. Dynamic viewport units take care of that, but browser support wasn’t there. “That actually started out at zero for everyone, but we can see that in a pretty short timespan it’s gone from zero to 100%. That usually doesn’t happen in the space of a single year,” Jägenstedt points out.

“This is more effective.We’re not doing more work. We’re probably doing less work in total by focusing on it at the same time.It’s simply a win-win to do this coordination.”

Scrolling is another area where mobile brings a number of different interoperability issues for developers. “What happens when you touch your phone and move your finger across browsers is not super consistent, the way the web developers see it: what happens to the address bar, what events are fired, what are the values reported to JavaScript for the width and height of different things?”

Interop 2022 is focusing on overscroll behavior — what happens when you scroll all the way down the page and start dragging — and scroll snap, which is used for swiping through product carousels. Because that’s not as interoperable across mobile and desktop browsers, developers have to code it in JavaScript, which doesn’t give as smooth an experience.

Byers points at touch, tap and scroll behavior in general as an example of building browsers as products rather than doing the engineering to get a high-quality web platform.

“When we all started taking our desktop browsers and our desktop browser engines and porting them over [to] mobile, we thought of it as a browser engineering problem and we didn’t think of it as a platform engineering problem as much as we should have. We all shipped browsers that worked on mobile, without really thinking: how do we need to update the standards?”

To make the web work well on mobile devices, browsers needed to put scrolling on a separate thread. “The only way scrolling was going to be smooth on low-power mobile devices was if we did it asynchronously for JavaScript. That fundamentally changed the model of the web platform and we didn’t update a single spec for it, I don’t think,” said Byers. Browsers added features like pinch to zoom, hiding address bars and the different ways tap and touch behave on screen, but the standards didn’t necessarily change to match.

“We accumulated all this debt in terms of the standards and the interoperability and the test suites.”

Initiatives like Interop are helping mobile catch up though, he believes. “The cost you pay to have an interoperable open platform is that it’s slow to catch up, but we’re finally getting to the point that the web platform on mobile is a serious computing platform. It’s not just that we have good browsers, but in the underlying platform increasingly we’ve got the standards [and] we’ve got the consistent behavior you can rely on. There’s still work to do, but I think we’re getting to the point that the web on mobile is now the predictable reliable platform that you can bet your business on the way it became on desktop a decade ago.”

Looking Forward Together 

The work on color spaces and functions is important because while displays are getting better and better, the specifications for color management and taking advantage of the wider color gamut haven’t quite kept up. The CSS Color Module is trying to address that. “We have displays that show color more vibrantly and gradients that just look better than before,” said Jägenstedt. The Interop work will help browser makers figure out “how do we actually go and implement this in our browsers, without using more memory.” Without this feature, pages can fall back to less vibrant colors; with it, “designers will make use of this to make more vibrant designs”.

Work is also continuing on the five focus areas from 2021: Safari has continued to catch up on aspect ratio, flexbox, grid and transforms. But more importantly, all four browsers are much closer to parity on all the Interop priorities than they were six months ago (which was already a big improvement over the level of interoperability before Compat 2021).

Having clear metrics means you can see how good the progress on interoperability is already.

Three of the focus areas for Interop 2022 are slightly different though. Rather than focusing on areas where browsers are ready to move ahead and can start work immediately, these are what Jägenstedt terms “investigation efforts” into areas where developers or web users are seeing problems but there isn’t yet a shared test suite to use as a metric. “We’ve said let’s come together and do the work to figure out where the specs are lacking and what tests we need to write, so that come next year we could include these as focus areas in 2023 if the evidence is there.”

Viewport measurement is a good example. “We know that there are differences between browsers in what happens with these JavaScript APIs and events that have fired and CSS units,” Jägenstedt said — but the automated tests aren’t finished, so engineers from the different browsers have collaborated on a list of issues that need resolving. “I’m bringing those to the CSS working group so we can get these specs refined and then write the tests the next time around.”

“Think about it as a trampoline. When we know something’s important, but we don’t know how to do it yet, this is like a stepping stone to include it the next time around.”

These more speculative investigations do contribute to the Interop metrics, but all browsers get the same score for them, underlining the point that making progress on new standards and tests is a team effort.

“It’s not just everyone deciding to push,” Byers suggests. “It’s doing the work to find the areas of common interest so that we can all agree on what’s worth pushing on.”

“This is one of the things I love about working on the web platform, is that when you can find allies that care about the same things you can move mountains by saying ‘hey, we all want this done, let’s agree we want this done, let’s get it done’ and we all benefit.”

“The total value of the web is more than just the sum of the parts or what any of us could do individually. Ultimately, I think the superpower of an open platform like the web platform is it can be so much more powerful, so much more resilient than any platform owned by a single company.”