Chromium's Intent Process for Adding New Web Standards

This article provides a comprehensive overview of how the Blink-dev process regulates the introduction of new web platform features into the Chromium browser engine. It breaks down the critical stages of this governance model, specifically focusing on the "Intent to Prototype" and "Intent to Ship" milestones, and explains how engineers propose, test, and secure final approval from Chromium's API Owners to ensure global web compatibility and standardization.

Blink is the rendering engine used by Chromium, which powers browsers like Google Chrome, Microsoft Edge, and Brave. Because Chromium holds a massive share of the browser market, adding new web standards to Blink directly impacts the entire internet. To prevent broken websites, security vulnerabilities, and proprietary fragmentation, Chromium uses a strict, public governance model known as the "Blink Launch Process." Every step of this process takes place transparently on the blink-dev public mailing list.

Stage 1: Intent to Prototype (I2P)

The "Intent to Prototype" is the first formal notification that a Chromium team wants to explore a new web standard.

The goal of this stage is early transparency. Before engineers invest months into writing production-ready code, they must announce their plans to the broader web community. To file an Intent to Prototype, feature authors submit a standardized email to blink-dev containing:

  • An Explainer: A clear document detailing the problem the feature solves and how developers will use it.
  • Initial Specifications: Early drafts of the technical standard, usually hosted in a W3C (World Wide Web Consortium) or WHATWG (Web Hypertext Application Technology Working Group) community group.

An Intent to Prototype does not require formal approval to proceed. Once announced, engineers are allowed to start writing code in the Chromium repository. However, this code must be locked behind a runtime flag, meaning everyday users and websites cannot access the feature unless they manually enable it in the browser's experimental settings.

The Iteration Phase

Between prototyping and shipping, the feature undergoes rigorous testing and standardization. Engineers gather feedback from web developers, sometimes running an "Origin Trial" (via an Intent to Experiment) to test the feature on live websites securely. During this time, the feature's specification is refined based on feedback from other browser makers and standards bodies.

Stage 2: Intent to Ship (I2S)

The "Intent to Ship" is the final and most stringent gate in the Blink process. Filing this intent means the engineering team believes the feature is stable, standardized, and ready to be turned on by default for billions of users.

Because enabling a feature by default makes it a permanent part of the web platform, the requirements for an Intent to Ship are exhaustive. The proposal must demonstrate:

  • A Mature Specification: The technical document must be detailed enough that a competing browser could build an identical, interoperable version of the feature.
  • Web Platform Tests (WPT): A comprehensive suite of automated tests must be written and shared in a public repository used by all major browsers to guarantee consistent behavior.
  • Vendor Signals: The authors must request official stances from other browser engines, specifically Mozilla (Gecko/Firefox) and Apple (WebKit/Safari). While unanimous agreement is not mandatory, positive signals prove the feature is a true web standard rather than a Chromium-only addition.
  • TAG Review: The W3C Technical Architecture Group (TAG)—a committee responsible for the overarching design of the web—must review the feature to ensure it aligns with web architecture principles.
  • Security and Privacy Approvals: Dedicated internal teams must audit the feature to ensure it does not introduce new attack vectors or allow malicious user tracking.

The Role of API Owners and the Three LGTMs

An Intent to Ship cannot pass on its own; it is governed by a select group of senior Chromium engineers known as the API Owners. The API Owners act as the stewards of the Blink engine, evaluating whether a proposed feature benefits the open web and meets all engineering standards.

When an Intent to Ship is posted to blink-dev, the API Owners scrutinize the application. They frequently push back, asking for better documentation, more tests, or deeper collaboration with other browser vendors.

For a feature to be approved, it must receive at least three "LGTMs" (Looks Good To Me) from the API Owners, with no unresolved objections. Once the third LGTM is granted on the mailing list, the engineering team is officially authorized to flip the feature flag to "enabled by default" in the Chromium source code, scheduled for an upcoming browser release.