What is "Red APIs, the Standards Process, and Feature Detection" about?

Some browser APIs do not exist and may never ship. How the W3C standards process works, what to do when a capability is unavailable, and how to detect APIs at runtime.

What topics does "Red APIs, the Standards Process, and Feature Detection" cover?

This article covers: web API standards, W3C web standards, browser feature detection, web capabilities unavailable, electron vs capacitor, progressive web app native bridge.

Red APIs: What the Web Cannot Do Yet (and Why)

Green and light-green APIs are available today. Yellow APIs are experimental. Red APIs do not exist yet -- and in some cases, they never will.

Why Some Capabilities Will Never Come to the Web

The main reason a capability stays red forever is security. The open web means any website can run code in a browser. That is its power, but also its risk. Some hardware access or OS-level features create too large an attack surface to expose to arbitrary websites. A bad actor could silently exploit them, steal data, or take control of a device.

So certain things are deliberately kept out of reach for web apps running in a browser URL context. If your product genuinely depends on one of those capabilities, you have two real options:

Ship as a PWA through an app store. A Progressive Web App packaged and published to the App Store or Play Store can bridge JavaScript to native code. This gives you access to platform APIs that the browser will not expose. On mobile, frameworks like Capacitor (from the Ionic team) and the older Apache Cordova (originally PhoneGap) handle that bridge.

Wrap in a native desktop container. For desktop, Electron embeds your web app inside a native shell with Node.js access. VS Code, Slack, Figma -- all Electron. You write the same HTML, CSS, and JavaScript, but the container grants you capabilities a browser tab never would.

Browser extensions are technically a third option, but they are multi-origin by design -- they apply across websites, not to one specific app. Using one just to unlock a capability for your own product is an awkward fit.

How a New Web API Actually Gets Made

The standards process is worth understanding because it explains why capability support is so uneven across browsers.

It usually starts with a proposal, often a document or GitHub issue, from a developer, a company, or a browser team. Someone from a browser vendor has to be willing to champion it -- to say "we think this is a good idea and we will implement it." Without that, the proposal goes nowhere.

If a browser picks it up, the API typically starts as a yellow experimental feature. It might stay there for months or years while teams gather real-world feedback through origin trials and flag users. If the experiment goes well, the API ships as stable in that browser.

Whether other browsers follow is a separate question entirely. Each company has its own priorities, product policies, and opinions about what the web should and should not be able to do.

The W3C (World Wide Web Consortium) is the organization responsible for web standards. For an API to reach "recommendation" status, meaning it is officially part of the web standard, it generally needs more than one browser shipping it. If only Chromium implements an API and no one else does, the W3C typically will not put it in the recommendation track.

There are real examples of this: APIs that Chrome ships and maintains, that the standards body rejected or never progressed, because other browsers refused to implement them. They still work in Chrome. You can use them. But they are not standards. That distinction matters for long-term bets.

The flip side also happens: browsers that are slow to adopt. Safari added web push notifications more than seven years after Chrome and Firefox had them. Some APIs Apple has said they will not implement at all.

Feature Detection Is the Right Approach

Since API support varies so much across browsers and devices, the correct pattern before calling any capability is to check whether it exists first.

There is no navigator.supports() API. No universal function you can call with an API name and get a boolean back. Instead, most web capabilities expose themselves as a property on a global object -- usually navigator or window. If the browser does not support that API, the property simply is not there.

JavaScript

// Web Bluetooth
if ('bluetooth' in navigator) {
  // safe to use navigator.bluetooth
}

// Geolocation
if ('geolocation' in navigator) {
  // safe to use navigator.geolocation
}

// Screen Wake Lock
if ('wakeLock' in navigator) {
  // safe to use navigator.wakeLock
}

// Gamepad
if ('getGamepads' in navigator) {
  // safe to use navigator.getGamepads()
}

This check tells you the API is present in the current browser. It does not guarantee the underlying hardware exists or that the user has granted permission -- those are separate concerns. But it is the baseline that determines whether you can even attempt the call.

The right mental model is layered capability: build the core experience without any advanced API, then check and progressively add each capability only when you have confirmed it is available. That is what makes a web app genuinely cross-browser, not just Chrome-shaped.

Practice

0/6 done