Blink is the rendering engine used by Chromium.
To improve the open web through
Note that Blink code must conform to Blink Coding Style Guidelines NOT Chromium Coding Style.Chromium Embedded Framework is probably the easiest way to use Chromium (and thus Blink) on your platform.
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.
Compatibility risk is one of the most important decision criteria for enabling new web platform features by default.
Factors that decrease compatibility risk (in rough order of importance):
The amount of scrutiny a proposed feature receives is directly proportional to its compatibility risk. The review process consists of code reviews, announcements to blink-dev, and formal API Reviews. If the degree of compatibility risk is in question, we err on the side of caution.
In practice, the following tiers are good rules of thumb to know that the feature is on the right track (ordered by increasing risk to compatibility and therefore decreasing order of desirability):
We hope to work with other browser vendors to develop a common approach to shipping experimental features. For example, Mozilla has already embarked on a similar policy. As part of this process, we may revise our approach as we gain more experience with it or to align with other browser vendors.
In extremely rare cases, we may enable a feature by default before the feature's compatibility risk is as low as we'd like. In such cases, we will meet the following requirements:
Further, we will take on an active commitment to shepherd the feature through the standards process, accepting the burden of possible API changes.
We should not take this track lightly. Features that take this track must be explicitly approved during an API Review and should not be approved unless all other routes are exhausted.
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. Trivial changes should be labeled as such in their code review. They should be small fixes that have low risk of disrupting web developers.
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.
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 of the API directory, a directory that contains the files that control the API we expose to the web (e.g., the WebIDL files, CSSNames.in). When reviewing changes to these files, the API owners should ensure that the changes meet the project’s guidelines for new features.
The current list of API OWNERS is here, but the directory structure will be refactored and the location of the file will change.
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.
This document contains the list of upcoming topics and notes from past reviews.
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.
^ DeprecateAs is intended to replace MeasureAs in the IDL file. Specifying both is redundant.
* It takes 12-18 weeks to hit Stable once you enable instrumentation.
See this blink-dev thread for more information on deprecation.
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 work-arounds 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:
You can find answers to some of the most common web developer-facing questions in the Blink Developer FAQ.