Blink is the rendering engine used by Chromium.
To improve the open web through
technical innovation and good citizenship
Blink is an inclusive open-source community that values fostering a supportive culture. We welcome participation from anyone who shares our mission
Transparency is one of the core values of Blink. Our goal is for anyone to be able to participate, regardless of organizational affiliation. There are a number of areas where discussions take place:
- Chromium Bug Tracker: We use bugs to track and discuss desired features. We use Chromium's bug tracker, and mark our bugs with the "Blink" component. Click the star next to a bug’s name to receive email updates, and file new bugs here.
- Code Reviews: We use Rietveld, Chromium's code review tool, to comment on implementation strategies for changes we've decided to implement.
- #blink: We hang out on the #blink IRC channel on Freenode to have quick, informal discussions and answer questions. For more substantive discussion, a format with a permanent record is preferred.
- firstname.lastname@example.org is a general list for discussions relevant to the design and implementation of the project. The mailing list is analogous to chromium-dev and is the most high-traffic of the communication channels. There are also several more targeted sub-lists for discussion of specific areas of the codebase, which you can find here. None of these lists are appropriate for web development inquiries.
Watching for new features
For web developers interested in tracking new features, the signal-to-noise ratio of discussion forums might be too low to be useful. There are several dedicated channels for staying up-to-date on new features:
- Beta Chromium blog posts: For each new Chrome Beta release (~every six weeks), the Chrome team publishes a blog post outlining changes to the web platform and the Chrome Apps & Extensions APIs. Here's an example of one of these posts.
- chromestatus.com: A dashboard where we track new feature development. Learn more in the “Feature Dashboard” section below.
- bit.ly/blinkintents: A Google Spreadsheet that lists all "Intent" threads and their approval status.
- Chrome Developer Relations: Chrome DevRel posts about new features on both Twitter (@ChromiumDev) and Google+ (+GoogleChromeDevelopers).
- Blink launch tracking bugs: These bugs track new features on the Chromium issue tracker. You can find launch bugs by applying the filter Type=Launch-OWP (OWP stands for "open web platform").
- email@example.com: a high-traffic list for Blink code reviews. The code for all new features gets reviewed on this list.
Committing and reviewing code
The process for becoming a committer
or an OWNER is the same as for the larger Chromium project, and code changes are approved by OWNERS
. Experience with the codebase
from working on WebKit will be taken into account to accelerate the process of becoming an OWNER.
Blink is implemented on top of an abstract platform and thus cannot be run by itself. The Chromium Content module
provides the implementation of this abstract platform required for running Blink. Developing for the Content module is covered in the Chromium developer docs.
Testing your changes can be done with a build of Content Shell or a full Chromium build. For some tips and suggestions on debugging Blink, see the page on Getting Started with Blink Debugging
Blink code uses the Blink Coding Style Guidelines
How do I port Blink to my platform?
Blink runs on an abstract platform inside a sandbox and therefore has few operating-system-specific dependencies. This design has two consequences: (1) Blink cannot run alone, and (2) porting to other platforms happens at a different layer. Instead of adding platform-specific code to Blink, you should use Chromium’s content layer, which provides an implementation of this virtual platform on a wide variety of operating systems including Windows, Linux, Mac OS X, and Android. A separate project called the Chromium Embedded Framework
is probably the easiest way to use Chromium (and thus Blink) on your platform.
Web Platform Changes: Guidelines
In addition to making the web platform faster and more secure, improving the web platform also means adding new functionality and removing cruft. To fulfill our good citizenship mission, we need to be careful to change the web-facing API in a transparent, responsible, and compatible manner. We measure success as moving the open web platform forward as a whole, not just moving one implementation forward.
In practice, we strive to ensure that the features we ship by default have open standards. As we work on features, we track their progress in the web standards community with the Chromium Features Dashboard, which lets us be transparent about the status of each feature and about how we make decisions about which features to enable by default for the open web.
These guidelines cover non-trivial changes that are exposed to the open web or in some other way have implications for web developers, including changes that add or remove functionality or APIs. Changes that are not exposed to the open web (e.g., user interface features, extension APIs, or testing infrastructure) are outside the scope of this policy.
Policy for shipping and removing web platform API features
As browser developers, we find that there’s often tension between moving the web forward and preserving compatibility. On 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. By definition, when any vendor ships a new feature (or is the first to remove an obsolete feature), the API change is not yet interoperable, so cross-browser compatibility is sacrificed, even if briefly. This section outlines our approach to resolving this tension.
Evaluating “interoperability and compatibility risk”
Interoperability risk is the risk that browsers will not eventually converge on an interoperable implementation of the API. Interoperability at a given time point is not a well-formed concept, because unless every browser shipped new features at exactly the same time then there is a period of non-interoperability. In practice, we forecast “interoperability risk” (a) by observing the public behavior of others in the web ecosystem. Heuristics that decrease risk a priori for an unshipped feature include, in rough order of importance:
- Other vendors already shipping compatible implementations
- A mature specification in the relevant standards body
- Positive signals from other browser vendors
- Lack of negative signals from other browser vendors
- A small API footprint
Compatibility risk is the likelihood that a change will break existing web content loaded in Chromium. We use the usage data from https://www.chromestatus.com/metrics
and feedback from web developers to guage the exent of compatibility risk. Compatibility risk is especially common with API removal, but is also a factor when adding new features (e.g. Unprefixed CSS Animations
Evaluating “moving the web forward”
A change to Blink’s API surface is said to “move the web forward” if it either (a) enables developers to build compelling applications for a large number of users, both now and in the future, and/or (b) reduces code complexity in Blink or Chromium.
Bucket (a) is subjective and changes over time. In 2014, we believe the most important changes for developers---and, by extension, users---are those that make the web more performant and easier to use on mobile devices. For more information, see the 2014 Blink goals brainstorming thread
Bucket (b) is important to make sure that the web’s progress is not overly constrained by its legacy. Simplifying the codebase allows us to make performance improvements, more quickly add more important features, and reduce binary size. In most cases, we believe these benefits will extend to other browsers as well.
Balancing “moving the web forward” and “interoperability and compatibility risk”
To manage the project-wide tension between moving the web forward and interoperability and compatibility, we ask of each proposed API change: does this individual change strike the right balance between making the web better and minimizing interoperability and compatibility risk?
In an ideal world, all changes would both drastically move the web forward and involve zero interoperability and compatibility risk. In practice, this is rarely the case; features fit somewhere else on this chart:
Blink’s willingness to accept a change is largely determined by the change’s location on the chart above:
- If a change has low interoperability and compatibility risk and significantly moves the web forward, Blink usually welcomes it (e.g., shipping unprefixed CSS Transforms).
- If a change has low interoperability and compatibility risk but isn’t expected to significantly move the web forward, Blink usually still welcomes it. Occasionally, Blink will reject changes in this bucket to avoid technical complexity (e.g., not shipping our old implementation of CSS Variables).
- If a change has high interoperability risk and isn’t expected to significantly move the web forward, Blink will usually not welcome it (e.g., not shipping canvas supportsContext).
- If a change has high interoperability risk but is expected to significantly move the web forward, Blink will sometimes welcome it after careful, publicly-explained consideration (e.g. shipping Shadow DOM). In such cases, the implementer is expected to:
- Propose an editor’s draft (or equivalent) to the relevant standards group.
- Discuss the feature publicly with implementers of other browser engines.
- Take on an active commitment to shepherd the feature through the standards process, accepting the burden of possible API changes.
Of course, equal minds can disagree about the fuzzier aspects of these policies. For example, if a change increases runtime performance but consumes more battery, does it “move the web forward”? Or: what combination of the heuristics above precisely constitutes “high” compatibility risk?
To equitably resolve these kinds of questions on a per-change basis, Blink has a well-defined process
for discussing and approving web-facing API changes. It consists of code reviews, announcements to blink-dev, and formal API review meetings. The most formal requirement of the process is that API changes must receive an LGTM from at least three different API owners
before enabled by default on trunk. The API owners are responsible for making sure the policy described above is applied appropriately on a per-change basis.
Trivial platform changes do not need to meet the requirements above. For example, changes to existing APIs to improve compliance with web standards or to fix bugs are welcome. When in doubt, please send at a PSA to blink-dev or ask an API OWNER for advice.
However, any new API (no matter how small) is considered non-trivial. Trivial changes should be small fixes that have low risk of disrupting web developers. Trivial changes should be labeled as such in their code review, and may still require the LGTM of one API OWNER if they change the stable-build output of the webexposed tests.
If we’re unsure about the extent to which a change will impact web developers, we may ask the contributor proposing the change to provide data quantifying the impact. If a project member questions whether a change is trivial, we will err on the side of caution and ask the contributor to meet the requirements above.
Historically, browsers have relied on vendor prefixes (e.g.,
) to ship experimental features to web developers. This approach can be harmful to compatibility because web content comes to rely upon these vendor-prefixed names. Going forward, instead of enabling a feature by default with a vendor prefix, we will instead keep the (unprefixed) feature behind the “enable experimental web platform features” flag in
until the feature is ready to be enabled by default or exposed for a limited duration origin trial
Web Platform Changes: Process
Launch process: launching a new feature
You do not need to use this process if:
- Your change does not affect web API behavior to the point that developers need to be aware of it.
- Your change is trivial and your reviewer agrees
- You must still create a chromestatus entry for the feature if none exists or update any existing entry.
- Your team has received explicit permission not to use this process
- You must still create a chromestatus entry
- Send a "Web-Facing Change PSA" email to chromium-dev (CC blink-dev)
Note: You can combine the intent to implement email with an intent to experiment or with an intent to ship. You must still complete steps 2 - 4.
- Email blink-dev using the “Intent to Implement” template.
Create an entry on chromestatus.com.
- Formal approval isn't necessary to proceed with implementation
- Code cannot be checked into trunk without an LGTM in code review
- Opposition on the "Implement" thread will likely resurface when you try to ship, so try to resolve issues early
File an OWP launch tracking bug
- You'll need to use an @chromium.org account for chromestatus.com. If you don't have one, please fill out this form.
- If you have trouble with chromestatus, please open an issue on GitHub.
Most changes should start a TAG review.Implement your change as a Runtime-Enabled Feature.Your feature should have interop tests, preferably web platform tests. If Chrome is the first one implementing a spec, the requirements for web platform test coverage + quality will be fairly high for shipping.To run an Origin Trial, send an email to blink-dev using the “Intent to Experiment” template.
- Some launches may require a formal Chrome review. If your feature has privacy, legal, or UI impact, please email firstname.lastname@example.org to set a review in motion.
When your feature is ready to ship, email blink-dev using the “Intent to Ship” template.
- Your feature should meet the guidelines for experimentation.
- You need at least 1 LGTM from an API owner to move forward.
- At the end of the experiment, you must update this thread with:
- What you learned
- How the feature has changed
- Whether the feature is cut, needs more experimentation, or will ship
Enable by default.
- Respond to any feedback or questions raised in the thread
- You need at least 3 LGTMs from API owners to launch.
- If you have resolved all feedback and are blocked on API owner LGTMs, add email@example.com requesting final approval.
Launch Process: removing a feature
Read the guidelines for deprecating a feature
Measure feature usage in the wild
Email blink-dev using the "Intent to Remove" template.
Respond to any feedback or questions raised in the thread
You need at least 3 LGTMs from API owners to remove.
If you have resolved all feedback and are blocked on API owner LGTMs, add firstname.lastname@example.org requesting final approval.
Notify developers and measure usage.
Update the appropriate chromestatus entry, noting the feature as deprecated. Make sure the entry links to suggested alternatives.
Notify developers by adding a deprecation console message.
Point to the updated chromestatus entry in the console message.
Add the API to the big switch in UseCounter::deprecationMessage.
Give developers as many milestones as possible to respond to the deprecation.
Instrument your code by either:
Adding DeprecateAs=[your enum value here] to the feature's IDL definition.* (See window.performance.webkitGetEntries)
Adding a call to UseCounter::countDeprecation somewhere relevant (as we did for the prefixed Content Security Policy headers).
Remove the feature.
If you are unsure of when a feature could be removed, or would like to discourage usage, you may deprecate a feature without a removal deadline. This is strongly discouraged and will require significant justification to API Owners:
* It takes 12-18 weeks to hit Stable once you enable instrumentation. See this thread for a discussion of which usage percentages are safe to remove.
Lessons from the first year of deprecations and removals
- We should weigh the benefits of removing an API more against the cost it has. %pageviews by itself is not the only metric we care about.
- The cost of removing an API is not accurately reflected by the UseCounter for older, widely implemented APIs. It's more likely that there's a longer-tail of legacy content that we're breaking.
- We shouldn't remove APIs that have small value on the path towards a removal that has significant value. Getting rid of attribute nodes *is* valuable and would benefit the platform. Getting rid of half the attribute node methods is not. So we should evaluate the usage of all the APIs we need to remove together in order to get there. Also, if we remove them, we should remove them all in the same release. Breaking people once is better than breaking them repeatedly in small ways.
- We should be more hesitant to remove older, widely implemented APIs.
- For cases where we're particularly concerned about the compatibility hit, we should do the removal behind a flag so that we can easily reenable the API on stable as we don't know the compat hit until the release has been on stable for a couple weeks.
Here's the current list of API OWNERS.
All members of the project are responsible for enforcing that new features follow the project’s policies. Project members who feel that a feature is violating the policy should raise the issue first with the contributor and, if that doesn’t resolve the issue, with the project’s public mailing list.
To complement this project-wide responsibility, we have a set of API owners who are listed in the OWNERS file for the expected output of tests that monitor much of the web-exposed surface area of blink (eg. these). When reviewing changes to these files, the API owners should ensure that the changes meet the project’s guidelines for new and removed features.
API Review meetings will be scheduled when API discussion over email is insufficient (per the Launch Process). API owners and contributors of features under discussion are welcome to attend. The purpose of the API Review meeting is to provide a high-bandwidth forum for discussion between API owners and feature implementors. The group makes decisions by consensus; at least three project OWNERS must be present for quorum. After the meeting the organizer will send notes, including any decisions, to blink-dev.
To improve transparency, we track development of new features on our Feature Dashboard. For each feature, the dashboard tracks our implementation status, the feature's progress through the standards process, our understanding of the opinion of other browser vendors and other key metrics.
We associate each value with a shade of red or green, corresponding to how the value reflects our web citizenship. For example, “opposition from another browser vendor” is red and “a similar implementation in another browser” is green. Viewed in aggregate, these colors provide a quick snapshot of the project’s overall web citizenship.
The dashboard data itself is also a useful high-level record of when features were implemented and a peek at what’s coming next. If you’d like to monitor lower-level changes as they happen, check out our Gitiles and SVN logs.
Guiding Principles for Process
- Minimize interoperability and compatibility risk for released features.
- Minimize process burden once a change has been LGTMed by API owners.
- Minimize ambiguity.
- Block bad engineering investments upfront.
- Block incomplete features from being runtime-enabled.
- Create an audit trail, not necessarily a single approval funnel for all changes.
- Prefer email over meetings.
Openness and interoperability are core to the web platform’s philosophy and success. We are committed to delivering features that are interoperable. In addition to the checks and balances in our release process, we prioritize testing as a way to promote compatibility across browsers. It is our intention to increase our investment in testing over time.
In 2012, we submitted a comprehensive Shadow DOM conformance test suite to the W3C. We’ll continue to create conformance test suites like these, so that implementations for new features are interoperable from the beginning. To incentivize this, the feature dashboard has a column for conformance tests. If a feature has a test suite, its cell in that column is green. Otherwise, it’s red.
Going forward, we’ll be working with the W3C and the broader web community to share more tests and testing infrastructure as a way to encourage interoperability.
We’ve also been collaborating with Adobe to host Test the Web Forward events, where web developers and spec authors work together to write conformance tests that all browsers are evaluated against. So far (April 2013) there have been four such events, the most recent hosted by Google in Sydney. We're committed to this effort and are currently organizing the next event in Tokyo.
If you encounter a bug in Blink or a browser interoperability issue, please file a bug here.
With Blink we’re excited about the freedom to dream big for the Web. When Chromium started, our goal was to change as little of WebKit as possible, easing integration with the WebKit codebase. With Blink we are excited to make large-scale architectural changes to the code, without having to worry about breaking other consumers of WebKit.
One change we’re planning is adding “out-of-process iframes”. These allow Chromium to separate individual parts of a page into separate sandboxed processes. Implementing this will require large restructuring of how iframes are handled in WebKit. Some of this restructuring is incompatible with other WebKit ports and has thus been delayed until now.
As another example, we’d like to fix our networking code to be faster and simpler. Our current networking code in WebKit is limited by old Mac WebKit API obligations which cannot be changed. Chromium has worked around some of these limitations over the years, but these workarounds have proven fragile and have long been a source of bugs. With Blink, we’re excited to refresh this networking code without forcing other WebKit consumers to break their WebKit API obligations.
Some of the other changes we're considering:
- Teach WebCore about multi-process history (currently it assumes same-process synchronous History access)
- Delete the Widget tree (a Mac WebKit1 constraint)
- Split WebCore into modules
- Experiment with moving the DOM into the JS heap
- Remove obscure parts of the DOM and make backwards-incompatible changes to obscure parts of the DOM that benefit performance or remove complexity.
- Use a modern, faster tcmalloc throughout all of Mac chrome
- Experiment with incremental or parallel layout
- Bring WebCore up to speed with DOM3 Events / [DOM] UI Events.
Changes previously considered and now done:
- Move code to use the sandbox Platform API directly instead of WebCore/platform where possible
- Establish a simpler, stricter tree-gardening system that does not require 2 full time engineers per day
- Replace WebKitIDL with WebIDL
The larger Blink team is divided in to a set of sub-teams each specializing in a particular part of the problem space and code base.
You can find answers to some of the most common web developer-facing questions in the Blink Developer FAQ.