3 ms·

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, ensu

by culi 3y ago

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?

CharlesW 3y ago
> What (other?) specific APIs are you interested in them focusing on? If a future Interop were to do this, I'd assume they'd define something like "profiles" of PWA capabilities (e.g. "Minimal" and "Extended") using lists like the ones at https://web.dev/learn/pwa/capabilities https://web.dev/learn/pwa/capabilities and https://whatpwacando.today/ https://whatpwacando.today/ for inspiration.
- JimDabell 3y ago
  Both of those websites include APIs that were implemented unilaterally by Google, while both Mozilla and Apple rejected them – mostly on privacy and security grounds. They aren’t a part of the web platform and aren’t on any standards track, they are Google APIs.
  - agust 3y ago
    These APIs are implemented in Chromium, included in a lot of browsers (Chrome, Edge, Opera, Vivaldi, etc.), and used by thousands of web apps. They are absolutely part of the web platform.
    - JimDabell 3y ago
      The web platform is not defined as “whatever Google chooses to implement”. It’s a collaborative effort. All of those browsers use Blink, Google’s rendering engine. It’s one single implementation. Something needs two independent implementations to become a web standard. If you look at the specifications, they will explicitly state that they aren’t standards. An interoperability project isn’t going to consider working on things that have been explicitly rejected by every implementer but one. That’s not how interoperability happens. Google need to go back to their specifications and resolve all the security and privacy problems with them so that they can convince at least one other rendering engine to implement them. If they can't do that, there’s no chance they are candidates for interoperability work.

by culi 3y ago

CharlesW 3y ago

> What (other?) specific APIs are you interested in them focusing on? If a future Interop were to do this, I'd assume they'd define something like "profiles" of PWA capabilities (e.g. "Minimal" and "Extended") using lists like the ones at https://web.dev/learn/pwa/capabilities https://web.dev/learn/pwa/capabilities and https://whatpwacando.today/ https://whatpwacando.today/ for inspiration.

JimDabell 3y ago
Both of those websites include APIs that were implemented unilaterally by Google, while both Mozilla and Apple rejected them – mostly on privacy and security grounds. They aren’t a part of the web platform and aren’t on any standards track, they are Google APIs.
- agust 3y ago
  These APIs are implemented in Chromium, included in a lot of browsers (Chrome, Edge, Opera, Vivaldi, etc.), and used by thousands of web apps. They are absolutely part of the web platform.
  - JimDabell 3y ago
    The web platform is not defined as “whatever Google chooses to implement”. It’s a collaborative effort. All of those browsers use Blink, Google’s rendering engine. It’s one single implementation. Something needs two independent implementations to become a web standard. If you look at the specifications, they will explicitly state that they aren’t standards. An interoperability project isn’t going to consider working on things that have been explicitly rejected by every implementer but one. That’s not how interoperability happens. Google need to go back to their specifications and resolve all the security and privacy problems with them so that they can convince at least one other rendering engine to implement them. If they can't do that, there’s no chance they are candidates for interoperability work.