Chromium Blog: Charting Browser Interoperability

Chromium Blog

News and developments from the open source browser project

Charting Browser Interoperability

Thursday, August 30, 2018

At this year's Google I/O, Ben Galbraith and Malte Ubl presented a chart during the Web keynote showing how the web is getting more interoperable:

This trend is really important to the Chrome team: web developers should be able to target the web platform, not four different (though overlapping) platforms. The chart was gleaned from the data in our Web API Confluence Dashboard. This project, originally designed for browser engineers, provides insights into web interoperability by tracking page-visible JavaScript APIs across many releases of the four major browser engines. Here’s an example:

Caption: Count of browser-specific APIs goes up when browsers are first to ship a new API, and down when either (i) a second browser implements a new API, or (ii) an API that failed to build consensus is removed by the one browser that implemented it. This chart plots a count of APIs shipped by only one of the four browser vendors over time. Interacting with the chart on the dashboard lets you open the list of APIs that corresponds to each count:

This information helps browser vendors prioritize work that will make the web more interoperable by either removing old browser-specific APIs or working with other vendors to implement APIs that are not yet widely supported. How APIs are collected In order to count APIs on the web, we first had to define what counts as a “web API”. The web is full of useful features, some of which are hard to define let alone detect. For this analysis we focused on JavaScript APIs that are visible to the developer when the page first loads. This leaves out several classes of feature, like CSS properties, HTML attributes, and APIs that are not available on page load (e.g., APIs are surfaced through interaction user/API interactions, or only available in certain types of workers). Nevertheless, it gives us a general view of programmable browser capabilities. Our JavaScript API-finding algorithm inspects the JavaScript object graph exposed on the global window object. Check out the link for details on how we managed to extract APIs from JavaScript prototypes. With the help of BrowserStack’s 1000+ browser/operating system configurations, we were able to gather API data for browser releases going back as far as 2012.

Determining if the web is healthy

Take a look at the metrics page on the dashboard and you’ll see a few different charts we’ve generated about the shape of the web. These metrics, and the APIs they represent, give web platform implementers insights into which APIs are fragmenting the web. APIs that fragment the web are:

Shipped by almost every browser, but not quite;

Removed by one browser, but not others; or

Shipped by one browser, but not others.

For example, our data shows that Safari is the only major browser that does not ship CSSStyleDeclaration#backfaceVisibility, Chrome has removed a number of SVGSVGElement APIs that are still shipped by all major browsers, and Edge is the only major browser shipping a number of BhxBrowser APIs. Querying the raw data yourself The dashboard isn’t intended to replace tools like MDN Docs or caniuse.com, but rather to illustrate trends that help browser vendors keep evolving the web towards interoperability. That said, the catalog page on the dashboard can give developers another source to corroborate interop info from manually curated sources. Try playing around with the search box above the API catalog. It supports some basic structured queries like in:firefox60 or notin:chrome66 for APIs in Firefox 60 or missing from Chrome 66, or RTCPeerConnection count:2 for RTCPeerConnection-related APIs shipped by exactly two of the browsers currently in view. Clicking the vertical ellipsis icon lets you add or remove dozens of browser releases from the grid, and the URL bar always contains a link that will get you back to the current query. Validating MDN browser compat tables We’ve also started using the data to help tech writers programmatically check their contributions to MDN’s excellent browser compatibility database. Try this out: # Clone MDN’s browser compatibility database git clone https://github.com/mdn/browser-compat-data.git cd browser-compat-data # Install dependencies npm install # Load confluence data for ServiceWorker npm run confluence -- --interfaces=ServiceWorker # Take a look at the differences that have been applied to your working tree git diff # Read the full list of parameters you can try on `npm run confluence` npm run confluence -- --help ConclusionWe hope both browser engineers and web developers can benefit from the dashboard. Check it out and let us know what you think over at the GitHub project that hosts the code.
Posted by Mark Dittmer, Software Engineer working on Web Ecosystem Infrastructure