There are two main reasons why we’re making this change.
In the Blink Architectural Changes section we have listed a few changes that will improve the speed and stability of the web platform in Chrome. Meanwhile, there are more improvements whose feasibility and performance benefits we're excited to investigate:
We're keenly aware of the compatibility challenges faced by developers today, and will be collaborating closely with other browser vendors to move the web forward and preserve the interoperability that has made it a successful ecosystem. We’ve also put a lot of work over the past few years into reducing that pain. Take one of the huge successes of the web standards community: the HTML5 Parser. All major browser engines now share the exact same parsing logic, which means things like broken markup, <a> tags wrapping block elements, and other edge cases are all handled consistently across browsers. This interoperability is important to Chrome and we want to defend it.
We see testing as the critical piece of web browser interoperability. Chrome currently shares and runs tests that were authored by Opera, Mozilla, and W3C Working Groups and we'll be doing a better job of this going forward. Developers need to be able to rely on Chrome’s implementation of standards, and that’s something we take very seriously. See the Testing section for our plans.
It's important to remember that WebKit is already not a homogenous target for developers. For example, features like WebGL and IndexedDB are only supported in some WebKit-based browsers. Understanding WebKit for Developers helps explain the details, like why
Today Firefox uses the Gecko engine, which isn’t based on WebKit, yet the two have a high level of compatibility. We’re adopting a similar approach to Mozilla by having a distinct yet compatible open-source engine. We will also continue to have open bug tracking and implementation status so you can see and contribute to what we’re working on at any time.
From a short-term perspective, monocultures seem good for developer productivity. From the long-term perspective, however, monocultures inevitably lead to stagnation. It is our firm belief that more options in rendering engines will lead to more innovation and a healthier web ecosystem.
Bringing a new browser engine into the world increases diversity. Though that in itself isn't our goal, it has the beneficial effect of ensuring that multiple interoperable implementations of accepted standards exist. Each engine will approach the same problem from a different direction, meaning that web developers can be more confident in the performance and security characteristics of the end result. It also makes it less likely that one implementation's quirks become de facto standards, which is good for the open web at large.
We’ve seen how the proliferation of vendor prefixes has caused pain for developers and we don't want to exacerbate this. As of today, Chrome is adopting a policy on vendor prefixes, one that is similar to Mozilla's recently announced policy.
In short: we won't use vendor prefixes for new features. Instead, we’ll expose a single setting (in
For legacy vendor-prefixed features, we will continue to use the
We really don’t want that; time spent papering over differences is time not spent building your apps’ features. We’re focusing our attention on making Chrome for Android the best possible mobile browser. So you should expect the same compatibility, rapid release schedule and super high JS and DOM performance that you get in desktop Chrome.
Your site or app's success on the mobile web is dependent on the mobile browsers it runs on. We want to see that entire mobile web platform keeps pace with, and even anticipates, the ambitions of your app. Opera is already shipping a beta of their Chromium-based browser which has features and capabilities very similar to what's in Chrome on Android.
Our goal is to drive innovation and improve the compatible, open web platform, not to add a ton of features and break compatibility with other browsers. We're introducing strong developer-facing policies on adding new features, the use of vendor prefixes, and when a feature should be considered stable enough to ship. This codifies our policy on thoughtfully augmenting the platform, and as transparency is a core principle of Blink, we hope this process is equally visible to you. The Chromium Feature Dashboard we recently introduced offers a view of the standards and implementation status of many of our implemented and planned features.
We know that the introduction of a new rendering engine can have significant implications for the web. In the coming months we hope to earn the respect of the broader open web community by letting our actions speak louder than words.
Nope, not at all! We're instituting strong guidelines on new features that emphasize standards, interoperability, and transparency. We expect to hold all new shipping features that affect web developers on the open web up to the same level of scrutiny. Technologies and standards developed primarily within Google will be held to the same guidelines as others.
Our main short-term aim is to improve performance, compatibility and stability for all the platforms where we ship Chrome. In the long term we hope to significantly improve Chrome and inspire innovation among all the browser manufacturers. We will be increasing our investment in conformance tests (shared with W3C working groups) as part of our commitment to being good citizens of the open web.
Opera will be adopting Blink, as mentioned by Bruce Lawson on his blog.
One of the keys to improving users’ experience is to give developers the tools, features, compatibility and performance they need to get the most out of the platform. Although the move is borne out of architectural necessity, it also allows us to prioritize the features that you need to build the next generation of apps, on both mobile and desktop. Similar to the introduction of V8, we hope this will spur innovation and you can and should expect the whole web platform to benefit.
Our ambitions are high and we continue to need the feedback and contributions that have made Chrome the browser it is today. You should also expect improved transparency in Blink's development processes, so getting involved will be easier than ever. Please, review the Chromium Feature Dashboard, experiment with future features in Dev/Canary and file any bugs you find.
~ FAQ authored by Paul Irish and Paul Lewis on the Chrome Developer Relations team
After the Blink announcement, the developer community submitted hundreds of questions and votes on Google Moderator (goo.gl/Uu0qV) that sought answers to your tough questions about Blink.
Engineering leads Darin Fisher and Eric Seidel are joined by PM Alex Komoroske and Developer Advocate Paul Irish