blink - the chromium projects
TRANSCRIPT
3/27/14 7:20 PMBlink - The Chromium Projects
Page 1 of 8http://www.chromium.org/blink
The Chromium ProjectsHomeChromiumChromium OS
Quick linksReport bugsDiscussSitemap
Other sitesChromium BlogGoogle ChromeExtensionsGoogle Chrome Frame
Except as otherwise noted, thecontent of this page is licensedunder a Creative CommonsAttribution 2.5 license, andexamples are licensed underthe BSD License.
Blink
Blink is the rendering engine used by Chromium.
Blink's Mission:
To improve the open web through technical innovation and good citizenship
Contents
1 Blink's Mission:2 Participating
2.1 Discussions2.2 Watching for new features2.3 Committing and reviewing code2.4 Developing Blink2.5 How do I port Blink to my platform?
3 Web Platform Changes: Guidelines3.1 Scope3.2 Compatibility3.3 Exceptions3.4 Trivial Changes3.5 Vendor Prefixes
4 Web Platform Changes: Process4.1 Launch Process: New Features4.2 Launch Process: Deprecation4.3 API Owners4.4 API Review4.5 Feature Dashboard4.6 Guiding Principles for Process
5 Testing6 Architectural Changes7 Developer FAQ8 Subpage Listing
Search this site
3/27/14 7:20 PMBlink - The Chromium Projects
Page 2 of 8http://www.chromium.org/blink
ParticipatingBlink is an inclusive open-source community that values fostering a supportive culture. We welcome participation from anyone who shares our mission.
Discussions
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 wherediscussions 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 "Cr-Blink" label. 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 apermanent record is [email protected] is a general list for discussions relevant to the design and implementation of the project. The mailing list is analogous to chromium-dev andis 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 canfind here. None of these lists are appropriate for web development inquiries.
Watching for new featuresFor 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 forstaying 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 andthe Chrome Apps & Extensions APIs. Check out the most recent post, which was for Chrome 27 Beta.chromestatus.com: A dashboard where we track new feature development. Learn more in the “Feature Dashboard” section below.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 (OWPfor “open web platform”)[email protected]: a high-traffic list for Blink code reviews. The code for all new features gets reviewed on this list.Blink source tree: The current source of Blink. You can also search and browse the code online.
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 thecodebase from working on WebKit will be taken into account to accelerate the process of becoming an OWNER.
Developing Blink
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 platformrequired 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 afull Chromium build. For some tips and suggestions on debugging Blink, see the page on Getting Started with Blink Debugging.
Note that Blink code must conform to Blink Coding Style Guidelines NOT Chromium Coding Style.
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 runalone, 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, whichprovides 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 theChromium Embedded Framework is probably the easiest way to use Chromium (and thus Blink) on your platform.
3/27/14 7:20 PMBlink - The Chromium Projects
Page 3 of 8http://www.chromium.org/blink
Web Platform Changes: GuidelinesIn 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 goodcitizenship 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 webplatform 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 communitywith 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 bydefault for the open web.
Scope
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 removefunctionality 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.
Compatibility
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):
Other vendors shipping compatible implementationsA mature specification in the relevant standards bodyPositive signals from other browser vendorsA small API footprint
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 ofdesirability):
1. Two other browser engines already ship roughly interoperable implementations in stable or experimental channels. In this situation, the feature is already a de factostandard. If a de jure standard does not yet exist, we should help create one.
2. One other browser engine ships a roughly interoperable implementation in a stable or experimental channel, we believe the feature to be stable, and we’ve consultedwith the appropriate standards body.
3. The appropriate standards body considers the feature ready for implementation. For example, the W3C issuing a Call for Implementations or publishing a CandidateRecommendation of the feature would meet this guideline.
4. The specification for the feature has been accepted by the appropriate standards working group (e.g., a First Public Working Draft in the W3C) and we’ve receivedpositive feedback from other browser engines about the feature’s feasibility and value.
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.
Exceptions
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:
We will propose an editor’s draft (or equivalent) to the relevant standards group.We will discuss the feature publicly with implementers of other browser engines.
Further, we will take on an active commitment to shepherd the feature through the standards process, accepting the burden of possible API changes.
3/27/14 7:20 PMBlink - The Chromium Projects
Page 4 of 8http://www.chromium.org/blink
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 areexhausted.
Trivial Changes
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 arewelcome. 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 aproject member questions whether a change is trivial, we will err on the side of caution and ask the contributor to meet the requirements above.
Vendor Prefixes
Historically, browsers have relied on vendor prefixes (e.g., -webkit-feature) to ship experimental features to web developers. This approach can be harmful to compatibilitybecause 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 about:flags until the feature is ready to be enabled by default. Mozilla has alreadyembarked on a similar policy and the W3C CSS WG formed a rough consensus around a complementary policy.
Web Platform Changes: Process
Launch Process: New Features
1. Decide if your change needs to go through this process.
If your change does not affect functionality exposed to the open web, you may skip the rest of this process. (The "open web" is accessible by entering a URL in the omnibox on a fresh Chrome install.)If you consider your change to be trivial, assert so in your patch. If your reviewer does not object, you may skip the rest of this process.If your change cannot be implemented in Blink but still exposes functionality to the open web:
Add an entry on chromestatus.com.Send a "Web-Facing Change PSA" email to chromium-dev (CC blink-dev).Skip the rest of this process.
Else, continue!
2. Email blink-dev using the “Intent to Implement” template.
If appropriate, create an entry on chromestatus.com and/or file an OWP launch tracking bug.In general, new features need a bug and an entry. Small changes and tweaks do not.
You should file an OWP launch tracking bug if you expect web developers will be interested in starring to follow along with the feature's development (e.g. the Chrome for Android Web Audio OWP launch tracking bug was starred by 70+ people).You should create an entry on chromestatus.com if you think web developers or other browser implementors will be interested in seeing this in the Chrome release notes.
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.com, please open an issue on GitHub.
No formal approval is needed to proceed with implementation, but it's in your interest to build consensus: code cannot be checked into trunk without an LGTM in code review, and opposition on the "Implement" thread will likely resurface when you try to ship.Typically API OWNERS or other interested folks will reply with feedback within a week. If you don't get any feedback, that's fine. Feel free to move forward with implementation.You can collapse steps 2, 3, 4 and skip to step 5 by sending an "Intent to Implement and Ship" email. Follow the instructions in the “Intent to Implement” template.
3. Implement your change as a Runtime-Enabled Feature.
4. Email blink-dev using the “Intent to Ship” template. Wait for LGTMs from at least 3 API Owners.
3/27/14 7:20 PMBlink - The Chromium Projects
Page 5 of 8http://www.chromium.org/blink
An in-person meeting will be scheduled if either a) 7 days pass without 3 LGTMs or b) an OWNER requests one.We clear the "unresolved intents" queue on Tuesdays, so usually you can expect a reply on or before the Tuesday after you send your intent.
5. Enable by default.
Launch Process: Deprecation
1. Decide if your feature needs to go through this process.
You can skip 2-5 if you’re removing a trivial feature (e.g. a quirk that is exclusive to WebKit, like RangeException).(In general, you don't need to be overly cautious removing features because Canary, Dev, and Beta users will complain if you break the web. That will give you a chance to revert your change before it reaches Stable. But if your reviewer suggests going through the rest of this process, do it.)
2. Carefully consider whether you can jump straight to deprecation without first measuring the feature's usage in the wild.
If you're sure you're not going to cause compatibility problems, then you don't need to measure. If you're unsure, then measuring is probably a good idea.To measure:
Add your feature to the UseCounter::Feature enum.Add MeasureAs=[your enum value here] to the feature's IDL definition.*
3. Email blink-dev using the "Intent to Deprecate" template.
No formal approval is needed to proceed with deprecation, but it's in your interest to build consensus: code cannot be checked into trunk without an LGTM in code review, and opposition on the "Deprecate" thread will likely resurface when you try to remove.Typically API OWNERS or other interested folks will reply with feedback within a week. If you don't get any feedback, that's fine. Feel free to move forward with deprecation.
4. Deprecate: notify developers and measure usage.
If you haven't, add your feature to the UseCounter::Feature enum.Instrument your code by either:
Adding DeprecateAs=[your enum value here] to the feature's IDL definition.*^ See window.performance.webkitGetEntries, for example.Adding a call to UseCounter::countDeprecation somewhere relevant (as we did for the prefixed Content Security Policy headers).
Notify developers by adding a clever deprecation message to the big switch in UseCounter::deprecationMessage. This will print a deprecation warning in the DevTools console.
5. Email blink-dev using the "Intent to Remove" template. Wait for LGTMs from ≥3 API OWNERS.
6. Remove.
^ 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 thread for a discussion of which usage percentages are safe to remove.
See this blink-dev thread for more information on deprecation.
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 shouldraise 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 thatcontrol 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 theproject’s guidelines for new features.
3/27/14 7:20 PMBlink - The Chromium Projects
Page 6 of 8http://www.chromium.org/blink
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
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 arewelcome 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 groupmakes 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.
Feature Dashboard
To improve transparency, we track development of new features on our Feature Dashboard. For each feature, the dashboard tracks our implementation status, the feature'sprogress 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” isred 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 changesas they happen, check out our Gitiles and SVN logs.
Guiding Principles for Process
Minimize 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.
TestingOpenness 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 checksand 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 implementationsfor 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 thatcolumn 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 allbrowsers 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 arecurrently organizing the next event in Tokyo.
If you encounter a bug in Blink or a browser interoperability issue, please file a bug here.
Architectural ChangesWith 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
3/27/14 7:20 PMBlink - The Chromium Projects
Page 7 of 8http://www.chromium.org/blink
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. Implementingthis 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 untilnow.
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 whichcannot 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.
Finally we’d like to explore even larger ideas like moving the entire Document Object Model (DOM) into JavaScript. This has the potential to make JavaScript DOM accessdramatically faster, but will involve a very large re-write of WebKit’s DOM implementation—something that would be difficult in WebKit which has two supported JavaScriptengines.
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 modulesExperiment with moving the DOM into the JS heapIncrease multicore use (e.g., html parser, style engine, javascript parser)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 chromeExperiment with incremental or parallel layoutFix memory leaks by removing the ScriptValue/ScriptState abstractions now that there’s only one JavaScript engine.Remove custom JavaScript bindings codeBring 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 possibleEstablish a simpler, stricter tree-gardening system that does not require 2 full time engineers per dayReplace WebKitIDL with WebIDL
Developer FAQYou can find answers to some of the most common web developer-facing questions in the Blink Developer FAQ.
Subpage Listing
Subpage Listing
ActiveDOMObjectBlink AutoRollBot (ARB)Blink Coding Style GuidelinesBlink Network StackBlink, Testing, and the W3CConversion CheatsheetDeprecating Features
3/27/14 7:20 PMBlink - The Chromium Projects
Page 8 of 8http://www.chromium.org/blink
Developer FAQDOM ExceptionsGarbage Collection for Blink C++ objects (a.k.a. Oilpan)Gardening Blink
Triaging Gasper AlertsGetting Started with Blink DebuggingHow repaint worksImporting Tests from the W3C (and contributing back)Public C++ APIRuntime Enabled FeaturesUnit Testing in BlinkV8 BindingsWeb ComponentsWeb IDL in Blink
Blink IDL Extended AttributesWeb Workers: Process types and Threads in Blink/Chromium
Subpages (21): View All
Sign in | Recent Site Activity | Report Abuse | Print Page | Powered By Google Sites