Chromium-based web browsers use the Blink rendering engine to transform code and resources into web pages you can view and interact with.
When engineers want to make a change to Blink, they post on the blink-dev mailing list to get approval to proceed. These mailing list posts are called Blink Intents.
In this article you'll find out how Blink Intents work, why they're important—and how new features make their way into Blink.
Chromium and Blink
Chromium is the open-source browser project on which Chrome and some other browsers and frameworks are built. Blink is the rendering engine used by Chromium.
For a new feature to land in Blink, it needs to go through the Chromium project's open development process. A "new feature" is any change or addition to browser code or architecture. That could be a new JavaScript API, a significant performance enhancement in Blink code, or some other change, to the way the browser looks or functions.
An open and collaborative process
Chromium is a huge, complex project with thousands of contributors. When there are changes to Chromium, each milestone is an opportunity to invite the wider web ecosystem to comment on design and implementation.
Wherever possible, new features must be interoperable across the web platform, and not implemented solely on one browser. Web developers don't want surprises: when browsers don't work the way you expect—or when you wind up having to write different code for different browsers and platforms. Blink Intents help structure and regulate the process of change, to make changes more predictable, and less of a surprise, which is good for web developers.
For users, browser vendors need to be careful that changes don't cause websites to stop working. Site owners quite often stop maintaining websites. Some sites haven't been updated in decades! Browser vendors need to consider this when making changes that might cause breakage.
From idea to proposal
Proposals for changes and updates to the web platform come out of research: consulting with users, businesses, browser engineers, web developers and other stakeholders. This research allows the Chrome team to work out what's missing from the platform, or what needs to change. Initially, a proposal for a change or a new feature on the web platform is just words on a page. Engineers share documents, for feedback and discussion from their colleagues.
An example: FedCM
Federated Credential Management (FedCM) is an API to provide new and better mechanisms for platforms that manage user signup and login, known as federated identity—for example, when you select "Login with Google" or "Login with GitHub".
Once a proposal like FedCM is ready for public discussion, it gets published to GitHub as what's called an explainer. At this point, anyone can ask a question or comment on the design of a feature, by creating an Issue on the explainer repository on GitHub. Feedback might describe additional use cases or constraints, provide ideas for improvements—or just show support.
Once a proposal gets adopted by a standardization body, such as the W3C, stakeholders can join discussions and watch presentations in web standards groups such as the W3C Working Groups.
Blink Intents: milestones and progress
For each milestone when engineers are working on a new feature or a change to the Blink rendering engine, they publish a post on the blink-dev discussion group, explaining that they intend to move to the next phase towards implementation of a feature. These posts are called "intents". Anyone can subscribe to the blink-dev group, to get notified when there's progress with new features in Blink, or subscribe to an individual feature for updates.
Intent to Prototype: the first checkpoint
At this point, Chromium engineers can begin to implement a feature. This means that prototype functionality for the feature may be made available for developer testing behind a feature flag, initially in Chrome Canary, and then in other release channels. Any user can set a flag from the chrome://flags page to activate and test a feature in their browser.
However, not all flags can be set from the chrome://flags page. For more fine-grained control, you can run Chrome from a terminal, using command-line flags. Bear in mind that some new features are not available until the feature ships for testing in Chrome Canary—though this is quite rare. Some features don't have their own flag, but they're made available if the experimental-web-platform-features flag is enabled. This is generally the case for "smaller" features that take no more than three to six months to implement, at the most.
Gathering feedback on prototypes
Once prototyping of a new feature has begun, Chromium engineers invite discussion and early experimentation. Feedback at this point is critical for validating and iterating on proposals. Chromium bugs is the place to comment on the implementation in Chrome.
Intent to Experiment: testing in the real world
An Intent to Experiment post on blink-dev is an optional next step, if Chrome engineers want to request to run an origin trial.
Origin trials are a way to test a new or experimental web platform feature. You register for the origin trial of a feature, then get a token for the trial. The feature will be activated on any page that provides the token.
LGTM from Blink API owners
For progress towards implementation of a feature to proceed, the Blink API owners must give their approval by replying to an intent with a "looks good to me" post, known as an LGTM.
The Blink API Owners are a small group of Chromium contributors, highly experienced with the web platform and its APIs, and agreed by the Blink community to be in good standing, with a commitment to Blink's mission and values. As well as giving approval (or not!) for features to proceed towards implementation, the API Owners oversee the Blink Intent process itself.
An Intent to Experiment must get at least one LGTM from API owners.
The value of origin trials
Developers can sign up for the origin trial of a feature, and then test the feature in production in real-world environments, with real users—without users needing to take action for the feature to be activated. Developers can share the results of their tests, and that provides valuable insight and data to help iterate and evolve the feature.
Intent to Ship: the final milestone
The Intent to Ship signals that a feature is now complete and ready to be implemented for general availability, for all users in Chrome Stable without needing a flag or a trial token. An Intent to Ship must get three LGTMs from API owners, before implementation can proceed.
Rolling out new features
Once approved, a feature is merged into an upcoming release and then progresses through Chrome's Canary, Dev, Beta, and Stable channels. Testing and implementation of some features needs to be handled with special care, so some features are rolled out gradually, to an increasing proportion of users. Features can be also rolled back and reworked, if there are unexpected side effects.
Managing the feature lifecycle: deprecation and removal
There are two other types of Blink intent:
- Intent to Deprecate
- Intent to Remove
These might sound a bit sad, but they're actually critical to the success of Blink development.
An Intent to Deprecate is posted by engineers when they want to start warning developers that a feature is scheduled to be deprecated. For example, by providing support and information about the deprecation in the Chrome DevTools console.
An Intent to Remove is posted when engineers intend for code to be deactivated by default.
The importance of deprecation and removal
Deprecation and removal are both critical to the health of the web platform. They make sure Chrome can remove features that don't work well for end users or web developers—and help reduce the complexity of the codebase. For example, problems with the design of AppCache were discovered once it was used on production sites in stable browsers, and the API was eventually removed. Deprecations and removals also help to keep Chrome safe and secure, by reducing potential attack vectors.
Like with all Blink intents, the Chrome team do their best to approach decisions with care. They review feature usage rates and other data before proceeding. The bar for removing features is actually incredibly high, and a feature will only be removed if it's used by a very, very small proportion of users, and if better alternatives are available.
Keep up to date with Blink Intents
You can track progress of features on Chrome Status, where you can subscribe to updates, file bugs, and find other resources.
To track new features, you can also follow along with the Chromium Blog. You can keep up with all Blink Intents by joining the blink-dev discussion group. That can result in a lot of emails! Alternatively, you might prefer to subscribe to a single intent. You can view a spreadsheet of Blink intents at bit.ly/blinkintents. If you really like Blink Intents, you can even build on the automated Blink Intent Tracker services.
Next steps
Check out What are Chrome release channels?