August 30th, 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:
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 the 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
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
We 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