the Chromium logo

The Chromium Projects

Blink Values in Practice


The Blink project's core values are to promote a useful and thriving web, while being a good user agent and safeguarding the openness of the web. Our primary lever for doing this is in deciding what features to ship or unship to our users, which benefits our users directly.

Unlike many other platforms, the web has multiple implementations, which is useful for maintaining its openness. Blink developers try their best to work with those other implementations to ship a consensus feature all at approximately the same time. When we can do this, the web platform moves forward smoothly.

Other times, the priorities and values of the various implementations don't align so quickly. The Chromium project has been blessed with a large ecosystem of active contributors. As such, we can take on the responsibility of proving out features in our engine first, trialing them with users of Blink-based browsers ahead of general deployment across all engines and to more web users. If other engines do then deploy the new features, this increases the interoperable surface area of the web, which improves the experience of those users we do not directly serve.

For this to work, we have to ship each feature in a way that incorporates broad feedback and makes it easy for other engines to implement if and when they decide the feature is valuable for their users.

This document describes how the Blink project uses and evaluates the requirements in our launch process to ensure that new features put our values into practice.

Finding balance

For all browser developers, there is an inherent tension between moving the web forward and preserving interoperability and compatibility. On the one hand, the web platform API surface must evolve to stay relevant. On the other hand, the web's primary strength is its reach, which is largely a function of interoperability. And by definition, when any browser ships a new feature, the API change is not yet interoperable. So we need to balance some key risks while we improve the web platform.

Interoperability risk is the risk that browsers will not eventually converge on an interoperable implementation of the proposed feature. Interoperability cannot be determined only at a given point in time; since browsers ship features at different times, there is always a degree of non-interoperability on the web. Instead, we are concerned with long-term interoperability risk, which we forecast by observing the public behaviors of others in the web ecosystem, and we work to minimize via the launch artifacts discussed below. See the Blink principles of interoperability for a more in-depth discussion.

Compatibility risk is the likelihood that a change will break existing web content loaded in Chromium. Compatibility risk is especially common with API removal, but it is also a factor when adding new features: before shipping, we need to be as sure as we reasonably can that the feature will not change or evolve in backward-incompatible ways in the future, as such incompatible changes cause direct harm to our users. Additionally, there can be cases where even new features interact with old ones to cause strange compatibility issues. See the Blink principles of web compatibility and Web compat analysis tools for more on this subject.

In an ideal world, all changes would both dramatically move the web forward, and involve zero interoperability and compatibility risk. In practice, this is rarely the case, and a tradeoff needs to be made:

The role of the API OWNERS

To find this balance and resolve the above tradeoffs on a per-change basis, Chromium delegates to a trusted group, the Blink API OWNERS, to decide what web platform features are delivered to our users. Concretely, they are the final approvers in the Blink process, where Chromium contributors present a series of artifacts as part of their Intent to Prototype/Experiment/Ship.

These artifacts are a key part of the process, and much of the rest of this document is spent detailing them and why we think they are important enough to make them requirements before shipping a feature. Because of the amount of resources committed to driving the web forward through Chromium, we accept that the bar should be higher for us—we can't expect, time and again, that the burden of designing new features will be split equally with others. So, we need to do as much as we can to set up and encourage others to participate.

We have not always done this perfectly in the past, and to be honest, it’s unlikely we’ll always do it perfectly in the future. But we commit to trying to work well with others—even when we are implementing features ahead of others.

Launch artifacts that Chromium values


Explainers are a proposal's first contact with the world. Well-written and comprehensive explainers help other interested parties judge the value of a feature, by presenting the use cases, the research, and the tradeoffs involved in the design space. Notably, an explainer needs to assume minimal previous domain knowledge in order to serve these goals well.

In particular, an explainer should present a living record of:

Explainers should be documents that other implementers can easily read or skim to figure out whether they think a feature is worth investing in. If these other implementers have the time to do so, an explainer repository also serves as an entry point for them to engage in the early design process. Such early engagement is excellent news: it increases the chance of the feature launching to other engines' users, sooner.


A good specification is critical to other implementations being able to interoperably implement a feature, and to that feature eventually reaching users of those other implementations. Although our code is open source, and in theory anyone could implement based on it, good specifications have the following benefits:

As such, Chromium developers must ensure that any feature they intend to ship is backed by a specification (and tests) that is complete and thorough enough that a second engine can get a good start on implementing the feature interoperably.

The goal of a web standard is to be clear enough to develop a new interoperable implementation based just on the standard, but it's impossible to be this thorough for features that haven't yet been implemented multiple times. We always expect the second implementers to find mistakes and areas of the specification that assume the context of the first implementation.

Instead, we require that an experienced spec author be able to read the specification without finding aspects that would confuse a second implementer. To help get your specification to this level and check if it's there, we have the Chromium Specification Mentors program, which pairs Chromium developers with a trusted mentor to get a second set of eyes.

Finally, the most important part of specification writing is to keep up active maintenance of the specification even after Chromium ships the feature. This is especially true if a second implementer starts implementing and filing bugs based on their experience.


By contributing web platform tests for our proposals, we create a machine-checkable subset of the specification. In practice, this is essential to achieving interoperable implementations, as well as ensuring compatibility through preventing regressions. Of note is the dashboard, which enables in-depth comparison of cross-browser results and a resulting drive toward interoperability.

Additionally, by devoting the Chromium project's resources to writing web platform tests, we ensure that other implementations have a ready-made test suite when they go to implement the feature. This is excellent leverage: we can invest our resources in writing the tests, but they can be used by all future implementations as well, almost for free.

Chromium developers should strive for high levels of coverage for their feature's web platform tests suite. Ideally, something like 100% coverage of both "spec lines" and Chromium code would ensure that Chromium implements the spec faithfully, and that others will be able to leverage the tests to implement the spec in the same way. Some sample test suites which approach this goal include url/, streams/, and pointerevents/.

In practice, this is a hard goal to reach. We can try to approach it by annotating specifications with their associated tests, and running the appropriate Chromium code coverage tools. Another hurdle is that some things are not testable with current infrastructure. We have a dedicated team,, which works to improve our testing infrastructure and mitigate such gaps.

Web developer and end user feedback

The best evidence for the value of a feature is testimonials or data from users and web developers. Before launch, these can be gathered in a variety of ways, including Dev Trials, Origin Trials, or direct user and developer engagement in venues like the Chromium or specification issue tracker. After launch, metrics such as use counters can show how much uptake a feature is getting in the wild.

Collating this information together for easy consumption is an important final step in the process before shipping. The goal is to present a body of evidence that makes it easy for other engines to evaluate whether they would like to bring the proposal to their implementation, or not.

Browser engine reviews

The Blink process requires most features to ask for vendor signals because they can give us some of the most direct indications of interoperability risk and specification quality. The feedback we get from the other vendors comes in several categories, which get different sorts of attention from the API owners.

Wide review

There are specific groups, usually in the specification ecosystem, which are dedicated to reviewing feature proposals. The W3C TAG is one such group, whose reviews have a formal place in the Blink launch process. But the more such reviews we can gather, the better.

Other groups to consider are:

None of these groups are obligated to respond; many are busy with other reviews or with their own work. But we always attempt to reach out, and respond to any concerns or questions raised. And then we work to capture any answers, or resultant changes, in a permanent location like the specification or explainer.


Notably, these guidelines do not have an explicit requirement that a feature be standardized (as opposed to specified), or that a feature have multi-implementer consensus. Instead, factors like those are inputs into the overall evaluation. Indeed, all engines implement features ahead of others, or ahead of formal standardization. (See the "Browser-Specific" section of the Web API Confluence Dashboard). But our process requires significant up-front investment from Chromium contributors before a feature is considered ready to ship, to help promote our values.

Even if other browsers have not yet implemented a feature, these artifacts are important to the Chromium project. Creating solid explainers, specs, and tests, and gathering feedback and wide review, can move us toward future interoperability, and decrease the risk in the eyes of the API OWNERS. Indeed, even if other browsers are opposed to a feature, by taking the steps above, we can confidently state that we minimized risk, and layed out a well-lit path in case the other browsers change their evaluation or their priorities in the future. This shows that in addition to a feature promoting a useful and thriving web, and being designed well with respect to the priority of constituencies, we have made a strong effort to ensure the feature upholds the web's open nature as well.