Historically interop seems to have been focused more on CSS, but that's changed more and more. Even still many of the test areas include tests for workers, ensuring that the state of PWAs will also improve. And in 2023 they had an entire Modules section which heavily tested PWA/worker-specific functionality. Additionally, many of the APIs tested and investigated like OffscreenCanvas and mobile testing are very relevant to many PWA applications.

This year, like the year before, is the least CSS-centric interop. With sections for IndexedDB (which I've only ever seen relied on by PWAs) and Websockets and important accessibility improvements. And the 3 investigation areas (WebAssembly, Accessibility, and Mobile testing) are all very relevant to PWAs.

What (other?) specific APIs are you interested in them focusing on?

From what I remember, the consortium is maybe a dozen people? And these people also work for the browsers. The goal is to come together and find features that they all can work on or improve over a year, taking into account current roadmaps and workloads. Think of interop like the small extra tickets you can work on in between the main feature development at your day job.

Right now the focus has been very low level details about how browsers render content. These are the biggest areas for improvement as the JavaScript APIs are largely standardized and merged in from “upstream”.

I suspect we will continue to see more work done to patch holes between browsers, before we see a push to simultaneously implement new features across all engines at once.

That said, with Apple finally adding webpush to mobile Safari, we’re getting a lot closer to covering the needs of the vast majority of web apps that would benefit from PWA features. What sort of features are you wanting to take advantage of that are not present cross browser yet?

What would you consider part of a PWA focus area?

You link to https://web.dev/learn/pwa/capabilities and https://whatpwacando.today elsewhere, but I think many would consider many of those features to not be inherently PWA features. Many, _many_, of those features have wide usage outside of PWAs, which makes putting them into a "PWA" bucket somewhat meaningless. Constructing buckets like "Storage" or "Media" would probably be more meaningful to web developers.

If you look at the basic definition of PWAs, it's primarily about manifests and service workers, and about using the web platform in combination with these.

Manifests are hard to test automatically — their content is largely shown in differing parts of browser UI, and UI is by-and-large unspecified in web standards (because vendors want freedom to make their own UI decisions) — which makes including them difficult. It's also unclear how much there is in way of interoperability problems.

Service workers are definitely something that could be proposed (though haven't been in recent years); I again don't believe there's been that much in way of interoperability problems there recently.

It bypasses an app store model, you can install an app directly from a browser.

It's in their best interest to drag their feet on the issue and ensure that the pwa experience is disincentivised.

As for Firefox dropping pwa support I'm just not sure. It's probably maintenance cost.

Because it's a niche use case compared to the much much broader case of "display content."

> Why do we think there isn't a PWA focus area from the participating consortium?

Because most PWA work is Chrome's non-standards they push out with complete disregard to any and all objections from both Safari and Firefox?

Because Apple has a say in what features are added there, and they'll do whatever they can to keep slowing down the progress of Web Apps.