Google Splits With WebKit to Launch Blink Engine in Chrome 28
Google for Developers
Google separated Blink from WebKit because divergent multi-process architectures made joint maintenance unworkable, forcing Chrome to build an independent engine coupled strictly to its own content layer.
Google officially forked WebKit to create Blink, transitioning Canary immediately and scheduling Chrome 28 as the first stable release to run the new engine across desktop and Android in roughly ten weeks. (2:30)
Blink will run exclusively on Chromium's content layer rather than supporting multiple operating system ports, standardizing directly on V8 for JavaScript and Skia for graphics rendering. (10:26)
Blink adopted a strict no-vendor-prefixes policy for new web features, committing instead to runtime flags while systematically auditing, standardizing, or deprecating inherited -webkit- prefixes. (6:58)
Google clarified that active patch sharing with upstream WebKit will diminish rapidly as the codebases diverge, with no plans to integrate Blink's multi-process changes back into WebKit2. (12:34)
Detailed notes
## Background
Published on YouTube by Google for Developers on April 4, 2013, this video features Chrome platform leads answering the top community questions following the announcement of Blink. Engineering leads Darin Fisher and Eric Seidel, Product Manager Alex Komoroske, and Developer Advocate Paul Irish clarify architecture decisions, project timelines, and policies outlined on the project's developer FAQ.
## TL;DR
Following Google's announcement of the WebKit fork Blink, the Chrome platform team addresses major community questions about the engine's future, architecture, and integration timelines. The panel confirms that Blink will officially ship starting in Chrome 28 and operates against Chromium's content layer with deep V8 and Skia integration, removing the need for platform-specific `#ifdef` abstractions. They outline policies to eliminate vendor prefixes, clean up legacy DOM features without breaking the web, maintain existing user-agent strings, and eventually transition Android WebView to a Blink foundation. Additionally, the team clarifies the historical reasons for diverging from WebKit2, affirming that while patch sharing will diminish over time, collaboration across web standards bodies and with peers like Mozilla remains strong.
## Atmosphere & style
The session feels like an open, candid, and pragmatic roundtable discussion among experienced engineers navigating a major industry transition. Paul Irish moderates with developer-focused clarity, while Darin Fisher and Eric Seidel offer seasoned architectural insights balanced by Alex Komoroske's measured product perspective. Despite addressing high-stakes questions about technical divergence and industry politics, the tone remains collegial, transparent, and relaxed, seasoned with self-aware humor about user-agent strings, office neighbors, and the infamous `<blink>` tag.
## Bulletin
- [02:30](https://www.youtube.com/watch?v=TlJob8K_OwE&t=150s) Google officially forked WebKit to create Blink, transitioning Canary immediately and scheduling Chrome 28 as the first stable release to run the new engine across desktop and Android in roughly ten weeks.
- [10:26](https://www.youtube.com/watch?v=TlJob8K_OwE&t=626s) Blink will run exclusively on Chromium's content layer rather than supporting multiple operating system ports, standardizing directly on V8 for JavaScript and Skia for graphics rendering.
- [06:58](https://www.youtube.com/watch?v=TlJob8K_OwE&t=418s) Blink adopted a strict no-vendor-prefixes policy for new web features, committing instead to runtime flags while systematically auditing, standardizing, or deprecating inherited -webkit- prefixes.
- [12:34](https://www.youtube.com/watch?v=TlJob8K_OwE&t=754s) Google clarified that active patch sharing with upstream WebKit will diminish rapidly as the codebases diverge, with no plans to integrate Blink's multi-process changes back into WebKit2.
## Key takeaways
- [00:08](https://www.youtube.com/watch?v=TlJob8K_OwE&t=8s) Blink and WebKit have parted ways with no formal relationship, making ongoing patch synchronization unlikely as architectures diverge.
- [02:30](https://www.youtube.com/watch?v=TlJob8K_OwE&t=150s) At launch, Blink remains functionally identical to WebKit, preserving existing User Agent strings to avoid breaking compatibility.
- [02:30](https://www.youtube.com/watch?v=TlJob8K_OwE&t=150s) Chrome 28 is the target release for shipping Blink on stable desktop channels and Android.
- [04:59](https://www.youtube.com/watch?v=TlJob8K_OwE&t=299s) The team is exploring radical architectural ideas, such as housing the DOM directly inside JavaScript (V8) to remove C++ context switching overhead.
- [06:33](https://www.youtube.com/watch?v=TlJob8K_OwE&t=393s) Blink plans to prune obsolete, legacy DOM features like the <isindex> tag by leveraging Google Search web crawl data to quantify breakage risk.
- [06:58](https://www.youtube.com/watch?v=TlJob8K_OwE&t=418s) Vendor prefixes are discontinued for future features; runtime flags will gate experiments to prevent permanently locking engines into vendor-specific APIs.
- [09:28](https://www.youtube.com/watch?v=TlJob8K_OwE&t=568s) Blink avoids WebKit's platform fragmentation and #ifdef sprawl by targeting Chromium's virtual content layer exclusively.
- [10:26](https://www.youtube.com/watch?v=TlJob8K_OwE&t=626s) Standardizing strictly on Skia for graphics and V8 for JavaScript enables deep architectural optimizations previously restricted by WebKit's multi-backend requirements.
- [12:34](https://www.youtube.com/watch?v=TlJob8K_OwE&t=754s) The fork was driven largely by diverging multi-process architectures, as Chromium could not adopt WebKit2 without an unreasonable engineering rewrite.
- [16:46](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1006s) Android's future platform WebView will transition to a Blink- and Chrome-backed engine, unifying mobile browser infrastructure.
- [17:28](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1048s) The Dart VM remains absent from mainline Chromium due to language maturity and long-term maintenance standards, not technical or architectural barriers.
- [19:24](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1164s) Google views multiple independent rendering engines as essential to the web's health to prevent developers from coding to a single engine's quirks.
- [21:20](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1280s) Blink retains WebKit's mixed BSD and LGPL licensing model without any relicensing.
- [21:20](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1280s) Codec decoding like H.264 remains isolated within the Chrome browser pipeline and operates completely decoupled from Blink's core layout boxes.
- [26:40](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1600s) The team firmly rejected competing against Mozilla's Servo, contrasting Blink's production-oriented mandate with Servo's experimental research focus.
- [29:01](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1741s) Blink will never implement a '-blink-' vendor prefix or natively revive the legacy blink tag.
## Detailed walkthrough
### [00:08](https://www.youtube.com/watch?v=TlJob8K_OwE&t=8s) Introductions and the Future Relationship with WebKit
Developer Advocate Paul Irish introduces the session, noting that within a single day following the Blink announcement, hundreds of questions and votes poured in from the developer community. Joining him on the panel are Darin Fisher (Engineering Lead for the Chrome web platform team), Alex Komoroske (Product Manager on the Chrome web platform team), and Eric Seidel (a longtime WebKit contributor now on the Blink team).
Addressing a multi-part question from Peter Kasting regarding the formal relationship between WebKit and Blink, whether the Chromium port will be stripped from WebKit, and whether tooling or policies will exist to sync bug fixes and features across both engines, Eric Seidel clarifies the informal path forward:
> “There's no real formal relationship between the two teams.”
He explains that while the two projects will likely exchange ideas and share patches early on when the architectures remain close, the codebases will inevitably diverge over time, making direct patch sharing much harder. Eric leaves the decision of removing the Chromium port entirely to the WebKit community's discretion, adding that passionate contributors on both sides will remain motivated to share concepts. Alex Komoroske emphasizes that this mirrors Chrome's existing collaboration with other browser engines through standards bodies, informal discussions, and public bug trackers.
[02:30](https://www.youtube.com/watch?v=TlJob8K_OwE&t=150s) Release Timelines, Availability, and Android Integration
Addressing questions from Mihai in Bucharest and several other developers regarding when Blink will hit Canary and Stable channels, Alex Komoroske stresses that at launch, Blink is functionally identical to WebKit. Developers running the latest Canary build will already be running Blink without noticing any difference, as the User Agent string remains unchanged for the time being. Paul Irish confirms that Canary builds have already switched under the hood, but developers will face no sudden disruptions.
Turning to Android and the future of the stock browser, Darin Fisher explains that Chrome will use Blink uniformly across all platforms, while decisions regarding the legacy Android browser depend on the broader product cycle. Paul Irish points out that Chrome for Android and desktop will officially ship Blink starting in version 28:
> “So 28 is the first Chrome release.”
Paul notes that Chrome 28 is currently in Canary and is expected to hit the Stable channel in roughly ten weeks, with an Android beta heading to the Google Play Store along the way.
[04:59](https://www.youtube.com/watch?v=TlJob8K_OwE&t=299s) Exploring Architectural Ideas: Moving the DOM into JavaScript
Addressing Greg’s question about ambitious architectural changes mentioned in the announcement documentation—specifically the concept of moving the entire Document Object Model (DOM) directly into JavaScript to accelerate performance—Eric Seidel outlines how the engine currently operates. In the legacy layout, the DOM is implemented in C++ within WebCore. Whenever a script touches a DOM node, execution must leave the JavaScript virtual machine, cross the boundary into WebCore C++, and return. While this interaction is already heavily optimized, moving the DOM directly inside the JavaScript engine would allow scripts to manipulate nodes without ever leaving the virtual machine.
```mermaid
flowchart TD
accTitle: Legacy WebCore DOM Crossing vs Proposed Blink DOM Architecture
accDescr: Diagram illustrating JavaScript crossing into C++ WebCore compared to unified execution within the V8 engine.
subgraph LegacyArchitecture["Legacy WebCore Architecture"]
JSVM["JavaScript Virtual Machine (V8)"]
Boundary["Bridge Crossing Overhead"]
WebCore["WebCore (C++ DOM Implementation)"]
JSVM -->|"Script DOM Call"| Boundary
Boundary -->|"Context Switch"| WebCore
end
subgraph FutureBlink["Proposed In-JS DOM Architecture"]
UnifiedVM["JavaScript Engine (Direct DOM Storage)"]
FastAccess["Native In-VM DOM Access (No Crossing Overhead)"]
UnifiedVM --- FastAccess
end
```
Darin Fisher cautions that this concept is an experimental exploration rather than a guaranteed enhancement:
> “Crazy, because it's not exactly an automatic win.”
Darin explains that any radical re-architecture comes with distinct trade-offs that the engineering team must investigate carefully. Alex Komoroske adds that the project wiki is currently gathering a wishlist of bold ideas that were previously impossible when constrained by WebKit's architectural boundaries.
[06:33](https://www.youtube.com/watch?v=TlJob8K_OwE&t=393s) Deprecating Legacy Features and Ending Vendor Prefixes
The panel addresses plans mentioned in the documentation to make backwards-incompatible changes by stripping out obscure DOM features to shed technical debt and gain performance. Eric Seidel explains that this cleanup reflects an industry trend that began with HTML5, which purged obsolete elements like the `<isindex>` tag (an outdated HTML2/HTML3 concept) as well as unused entity reference nodes from the DOM specification.
Darin Fisher emphasizes the engineering philosophy behind these deprecations:
> “The idea is to identify the low hanging fruit, and clean up the platform, if we can.”
Darin notes that an engine cannot simply accumulate features indefinitely without degrading the platform over time, though removals must be handled cautiously through developer evangelism and migration paths so websites do not break. Alex Komoroske points out that Google has been indexing the web via search data to evaluate real-world usage and calculate the exact breakage risk of pruning specific APIs.
In terms of CSS and prefixes, Alex Komoroske notes:
> “We announced yesterday that going forward we'll have a policy of no vendor prefixes, which is similar to what Mozilla is doing, and the policy they've adopted.”
Alex explains that Blink will systematically audit inherited `-webkit-` prefixes on a case-by-case basis: unprefixing features that are stable, standardizing features that provide value, or fully deprecating nonstandard remnants until the engine is completely free of prefixes.
- Legacy tags such as `<isindex>` and entity reference nodes have already been slated for removal in WebKit and Blink following web standards.
- Google uses search index crawl data to measure the precise percentage of web pages relying on obscure DOM methods.
- Moving forward, Blink adopts a strict no-vendor-prefix rule for newly implemented web features, mirroring Mozilla's approach.
[09:28](https://www.youtube.com/watch?v=TlJob8K_OwE&t=568s) Avoiding Collaboration Bottlenecks via a Virtual Platform
Paul Irish presents a question asking how Blink will avoid the collaboration friction, review slowdowns, and architectural hurdles that plagued WebKit as more external contributors join and port it to other operating systems.
Darin Fisher responds that the fundamental difference lies in porting. Rather than scattering platform-specific code and operating system abstractions throughout the engine core, Blink operates against a unified virtual platform layer. Because Chromium's multi-process, sandboxed security model required stripping out all direct operating system dependencies from the WebCore layer years ago, Blink targets this single abstraction layer. Consequently, running Blink on new devices—spanning high-end desktop machines down to tiny embedded environments—requires little bespoke porting work within the rendering engine itself.
[10:26](https://www.youtube.com/watch?v=TlJob8K_OwE&t=626s) The Content Layer, Modularity, and Deep Integration with V8 and Skia
Darin Fisher explains that going forward, Chromium's content layer is the only platform that will support Blink. This architectural focus makes the Blink codebase extraordinarily portable. Developers have already achieved widespread success using Chromium's content layer—the multi-process embedding layer that wraps around Blink—to port the engine to other operating systems and diverse application types without needing to fork the project or inject excessive platform-specific code. This structure allows broad community participation without littering the source tree with conditional preprocessor directives (`#ifdef`s).
Alex Komoroske references a blog post Paul Irish wrote a few weeks prior detailing the difficulty of WebKit’s layered architecture, where every new port forced maintainers to bring a massive set of custom platform implementations to the table. In Blink, the content layer provides these components in a clean, cross-platform manner. Fisher emphasizes that while Blink is modular enough to allow embedders to strip out unused modules, Chromium prefers structural modularity over hacking up the codebase with preprocessor macros.
Addressing the dependencies of the engine, Irish asks whether V8 and Skia come bundled as part of this layer. Fisher confirms that both are implied; Blink relies strictly on Skia for graphics and V8 as its JavaScript engine. Komoroske points out that this tight coupling offers an unprecedented opportunity to optimize the interfaces between the rendering engine and its core subsystems. Fisher notes that both the V8 and Skia teams are eager to revamp their integration points with the renderer, which will involve deeper changes to those internal interfaces.
```mermaid
flowchart TD
accTitle: Chromium Content Layer and Blink Architecture
accDescr: Diagram showing how the Content Layer embeds Blink alongside V8 and Skia without ifdef sprawl.
subgraph ContentLayer["Chromium Content Layer (Multi-Process Embedding)"]
direction TB
Blink["Blink Rendering Engine"]
V8["V8 JavaScript Engine"]
Skia["Skia Graphics Library"]
Blink <--> V8
Blink <--> Skia
end
Embedders["Third-Party Embedders & Platforms"] --> ContentLayer
```
- Blink runs exclusively on Chromium's multi-process content layer, eliminating platform-specific variations within the rendering core.
- The codebase avoids macro sprawl: “We strive in the Chromium to modularize, as opposed to using preprocessor directives to hack up the code base,” explains Darin Fisher.
- Tighter coupling with V8 and Skia enables architectural interface redesigns that were previously constrained by WebKit's multi-engine support.
---
[12:34](https://www.youtube.com/watch?v=TlJob8K_OwE&t=754s) Upstream Contributions and the WebKit2 Multi-Process Split
Paul Irish asks whether changes made in Blink will be contributed back to the upstream WebKit project. Eric Seidel stresses that Blink and WebKit are now entirely separate projects with separate codebases, and Google has no active plans to backport patches. Drawing an analogy to WebKit's original fork from KHTML, Seidel notes that while many patches initially bounced between the two projects due to their close lineage, diverging code paths naturally reduce backporting over time. Komoroske and Seidel observe that while anyone in the open-source community is free to port patches, divergence will make it increasingly difficult. Fisher expects that although some Googlers may still submit changes to WebKit in the short term, those contributions will diminish.
Irish raises a pointed question from the community regarding the historical multi-process dispute: Google stated that difficulties working with WebKit2's multi-process model motivated the fork, yet Apple engineers have stated they invited Chromium to integrate its multi-process architecture into WebKit prior to the creation of WebKit2 and were refused.
Fisher confirms that Apple did express interest in Chromium's multi-process model shortly after Chrome launched. However, Chromium's architecture was already mature, tightly coupled to Chrome-specific libraries, and foreign to WebKit conventions:
> “However, we saw that as a mountain of work, a large, technically challenging engineering project for us.” — Darin Fisher
Because the engineering effort was prohibitive and timelines did not align, Google found no practical path to contribute that code to WebKit. Instead, both teams decided to collaborate where mutual benefit was highest: WebCore. Sharing the sensitive code responsible for HTML parsing, DOM construction, and CSS rendering delivered immense value for five years. However, Fisher explains that Google's desired changes to the shape of WebCore are fundamentally incompatible with what WebKit is prepared to accept. Seidel clarifies that comparing Apple's early offer to Google's later evaluation of WebKit2 compares two different architectures at two entirely different points in time—five years ago versus one or two years ago. Ultimately, both teams simply chose different architectures to solve similar problems.
- Eric Seidel on patch sharing: “And we don't have any plans, currently, to be moving patches.”
- Apple asked to adopt Chromium's multi-process architecture after Chrome's initial launch, but Chromium's infrastructure was already too deeply integrated with internal Chrome libraries to extract without massive friction.
- Both teams focused their shared energy on WebCore (HTML, DOM, CSS) where collaboration was most effective.
- Eric Seidel on the divergent paths: “The reality is they're just very different architectures to serve very different needs.”
Irish shifts the conversation to mobile, asking what the Blink announcement means for the Android WebView implementation. Fisher notes that public activity in the Chromium open-source project already reveals active development on an Android WebView API built on top of Chrome.
Fisher states that in the fullness of time, as that Chrome-based WebView lands in Android, Blink will naturally become the underlying engine for the platform WebView. The engineering team is eager to see WebView transition to a Chrome- and Blink-based foundation because having unified plumbing across the mobile browser and embeddable WebView enables the Chrome team to directly drive performance and platform quality forward.
- Android WebView development is actively underway directly within the Chromium tree.
- Once the Chromium-backed WebView ships to Android devices, Blink will replace the legacy WebKit WebView engine.
- Consolidating on Blink allows the Chrome engineering team to maintain and improve WebView alongside the mobile browser.
---
[17:28](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1048s) Scripting Engines, the Dart VM, and API Responsibility
Irish asks whether Blink will support multiple scripting languages, pointing toward community speculation around integrating the Dart VM. Fisher clarifies that the Dartium project already provides a Chromium build embedding the Dart VM via an existing patch that sits on WebKit without causing massive disruption. The absence of the Dart VM in mainline Chromium is not an architectural limitation of WebKit or Blink; rather, it is a deliberate decision tied to the maturity of Dart itself. Google is unwilling to make a permanent, long-term commitment in the shipping browser until the VM reaches the right milestone.
Komoroske underscores that the Blink project enforces stringent standards regarding web compatibility risk and shipping features responsibly. Fisher recounts an internal engineering maxim—that every addition must justify its place on the device:
> “I think the web platform is famous for having multiple solutions to the same problem. And we see that as a problem. We have to be responsible to not create more of those problems.” — Darin Fisher
Fisher emphasizes that Blink must avoid redundant ways of solving the same problem. Because deprecating platform APIs is historically painful and hazardous for developers, the engineering team intends to validate every feature thoroughly and commit only to capabilities they are prepared to maintain over the long term.
- Dartium proves that alternative VMs like Dart can integrate into the engine without disrupting the core architecture.
- Mainline Blink excludes the Dart VM not due to technical barriers, but due to product timeline decisions and long-term maintenance criteria.
- Blink's API policy seeks to eliminate platform redundancy to prevent future deprecation cycles.
---
[19:24](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1164s) Impact on Other Browsers and Google's Ongoing Role in WebKit
Irish reads a question submitted by user "spiffytech" asking how Blink will impact the myriad of other browsers that have historically adopted WebKit. Komoroske responds that Google fundamentally views multiple independent rendering engines as an engine of innovation that safeguards the long-term health of the open web. Fisher adds that while the Chromium team remains committed to web standards, shared web platform tests, and cross-browser consensus, having multiple implementations prevents web developers from writing code tailored to the quirks and bugs of a single dominant engine.
Seidel highlights that Blink provides other browser vendors with meaningful choices. However, he clarifies an important architectural distinction: embedding Blink is not directly comparable to embedding WebKit, because Blink is inseparable from the Chromium content layer. Any browser or application vendor wanting to leverage Blink must embed Chromium's content layer rather than treating Blink as a standalone drop-in component.
Returning to Google's relationship with WebKit, Seidel reminds the audience that Google contributed to WebKit long before Chrome was officially launched and anticipates continued contributions from Google in various capacities. Fisher notes that Google is not telling its engineers they are forbidden from contributing to WebKit; rather, the Chromium team itself is given full freedom to direct its focus toward Blink.
| Topic | WebKit Embedding | Blink Embedding |
|:--- |:--- |:--- |
| **Architectural Boundary** | Standalone rendering library with custom platform ports | Coupled to the Chromium Content Layer |
| **Dependencies** | Pluggable graphics and JS engines per port | Standardized on Skia (graphics) and V8 (JavaScript) |
| **Code Customization** | Relies heavily on `#ifdef` macros across platform ports | Structural modularity through the content layer |
| **Engine Diversity Goal** | Single codebase adapted across multiple platforms | Multiple independent browser engines adhering to shared web standards |
- Multiple competing rendering engines protect developers from relying on single-engine engine bugs and quirks.
- Embedding Blink requires integrating Chromium's content layer, unlike the standalone port structure of WebKit.
- Darin Fisher on Google's policy toward WebKit: “I think is important to say that, as Google, we're not telling people they shouldn't contribute to WebKit. We're just telling them that, feel free to focus on Blink.”
[21:20](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1280s) Open-Source Licensing and Codec Support
Addressing the licensing structure of the new fork, Darin Fisher clarifies that the team is not performing any relicensing as part of Blink's creation. Because WebKit itself historically absorbed source code from numerous external projects, Blink remains a mixture of licenses—primarily BSD and LGPL.
When Paul Irish asks whether Blink will continue to support the H.264 video codec, Fisher emphasizes that media format compatibility is fundamentally a browser-level concern: “Will it continue to support the H.264 codec? That's really more of a Chrome question.” Eric Seidel expands on this architectural boundary, pointing out that Blink operates completely decoupled from video decoding mechanics: “Blink doesn't know what codecs even exist. It has a box in which the video goes. And something outside of Blink makes the video go there.”
```mermaid
flowchart LR
accTitle: Separation of Blink Rendering and Media Codecs
accDescr: Diagram showing Blink rendering a video element box while external Chrome components feed decoded media streams like H.264 into it.
subgraph Browser["Chrome Browser Layer"]
A["Media Pipeline / Codecs (H.264, VP8)"]
end
subgraph Engine["Blink Rendering Engine"]
B["Layout Box (<video> container)"]
end
A -->|"decodes and feeds video frames"| B
```
[22:11](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1331s) User-Agent Strings and Web Compatibility
Addressing developer speculation over whether a new `Blink` token will appear alongside historic engine tokens like `KHTML` or `Gecko`, Fisher states that there are currently no plans to alter the user-agent string. Specifically, the version token following `AppleWebKit` and `Safari` will remain unchanged; only the version number appended to `Chrome` will continue to increment.
While the team openly laments the convoluted state of user-agent strings across the industry, they recognize the fragility of the broader ecosystem: “Because, like it or not, people do all kinds of interesting string compares against it,” notes Fisher. Alex Komoroske agrees that current user-agent strings are “crazy,” pointing out that if the string is ever modified in the future, the conversation will take place transparently on the open `blink-dev` mailing list. While Fisher recalls an effort from a couple of years earlier that successfully stripped out a few unnecessary tokens, Seidel and Irish summarize the core engineering constraint with a shared web-platform mantra: “Just don't want to break the web.”
[23:37](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1417s) Testing Blink and Following Ongoing Development
Turning to code availability, Fisher and Irish confirm that Blink is already accessible in Chrome Canary as of the day of the announcement, and developers can build Chromium with Blink directly from source. Seidel credits the team's infrastructure engineers who pulled an all-nighter to ensure that developers could compile Blink and that incoming patches could already be landed on day one.
To help developers track commits, architecture discussions, and bugs without getting overwhelmed, the panel highlights several resources:
- Joining the open `blink-dev@chromium.org` mailing list or the `#Blink` IRC channel on Freenode.
- Visiting `chromium.org/blink` for direct links to repositories, mailing list archives, and change sets.
- An IRC-based commit bot (modeled after WebKit’s bot) to announce commits in real time.
- Chrome beta release summary posts that outline newly enabled features, flags, and deprecated prefixes.
- Viewing `chromestatus.com`, a platform dashboard tracking feature implementation status and standardization progress across the entire browser ecosystem, which has already received contributions from engineers at Adobe and Mozilla.
[26:40](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1600s) Impact on Dart and Relationship with Mozilla’s Servo
When asked whether Blink’s separation from WebKit will influence the Dart language or result in a Dart VM being integrated into Chrome, Fisher and Seidel clarify that Dart remains an independent open-source project whose roadmap is unaffected by the rendering engine fork.
The panel also rejects the notion that Blink is positioned as an aggressive competitor to Mozilla's experimental Servo project, noting that the two initiatives serve fundamentally different purposes:
- **Blink**: A pragmatic, production-focused fork that iterates directly on WebKit’s established codebase to reliably ship software to users immediately.
- **Servo**: A ground-up research experiment built from scratch to explore radical concurrency and novel architectural concepts that may or may not eventually ship in a final browser.
Seidel explains that the ecosystem relies on both philosophies: “One of WebKit's goals was WebKit is not a science project. We're about shipping a product today. And the reality is the world and the web ecosystem need both kinds. We need exploratory crazy new things. And we also need to ship something today.”
The team describes their relationship with Mozilla as collaborative rather than adversarial. Seidel remarks that he can see Mozilla's San Francisco offices right from his window, prompting Fisher to joke, “Do they know you can see them?” Komoroske shares that visiting Mozilla engineers had stopped by the Google offices just days earlier to chat about their proximity and shared web standards goals.
[29:01](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1741s) Phasing Out Vendor Prefixes
Discussing how legacy `-webkit-` vendor prefixes will be handled, Komoroske reiterates that Blink will introduce zero new vendor prefixes going forward, relying instead on runtime flags for experimental features. Phasing out inherited prefixes, however, must be approached with caution on a case-by-case basis:
1. **Long-standardized features**: Where an un-prefixed implementation has existed and been broadly adopted for years while the prefixed alternative has fallen out of use, the legacy prefix will simply be removed.
2. **Non-standardized experiments**: Features that were never standardized will either be taken through the formal standards process or formally deprecated and scheduled for removal.
Fisher explains that vendor prefixes failed in their original goal because shipping prefixed APIs still locks the engine into supporting them permanently: “And the reason why we don't want to do vendor prefixes anymore is because, vendor prefix or not, when you add something to the platform and you ship it, you can get stuck with it.” Seidel underscores the absurdity of the current legacy prefix situation, remarking that standards bodies have even debated standardizing `-webkit-` prefixes directly into official specifications to maintain web compatibility—a scenario the team hopes to avoid. Both Fisher and Seidel conclude with absolute certainty: there will never be a `-blink-` vendor prefix.
[30:17](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1817s) Banter on the Blink Tag and Wrapping Up
The conversation closes on a lighthearted note when Paul Irish mentions a community request asking whether the newly named Blink engine might support the infamous `text-decoration: blink` styling. Darin Fisher dismisses the notion with a laugh, saying, “I'm pretty sure we will not be doing that,” before adding that it might only ever appear behind an experimental flag just for fun. Alex Komoroske recalls a running joke within the team that developers do not even need browser vendors to implement it anymore, noting that with Web Components, developers can trivially build custom `<x-blink>` elements if they truly desire the retro effect. However, he leaves no room for ambiguity about core engine support, declaring, “We will not ship the Blink tag.”
Paul Irish then officially concludes the Q&A session, expressing gratitude to everyone in the web developer community who submitted and upvoted questions. He directs developers seeking further details to `chromium.org/blink`, where Google has published a comprehensive overview of the Blink project, outlines of their policies regarding feature additions, and a Developer FAQ addressing additional technical questions not fully covered in the livestream.
- Darin Fisher joked that any support for blinking text would at most live behind an enable flag strictly for amusement.
- Alex Komoroske emphasized that developers can easily create their own custom `<x-blink>` tag using Web Components without native browser intervention.
- Viewers are encouraged to visit `chromium.org/blink` to read the project overview, policy guidelines for feature implementation, and the Developer FAQ.
## Notable quotes
> [29:01](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1741s) And the reason why we don't want to do vendor prefixes anymore is because, vendor prefix or not, when you add something to the platform and you ship it, you can get stuck with it. — Darin Fisher
> [17:28](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1048s) I think the web platform is famous for having multiple solutions to the same problem. And we see that as a problem. We have to be responsible to not create more of those problems. — Darin Fisher
> [26:40](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1600s) One of WebKit's goals was WebKit is not a science project. We're about shipping a product today. And the reality is the world and the web ecosystem need both kinds. We need exploratory crazy new things. And we also need to ship something today. — Eric Seidel
> [21:20](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1280s) Blink doesn't know what codecs even exist. It has a box in which the video goes. And something outside of Blink makes the video go there. — Eric Seidel
## Mentioned
Blink, WebKit, Chromium, Google, Google Chrome, Paul Irish, Darin Fisher, Alex Komoroske, Eric Seidel, Peter Kasting, Apple, Mozilla, Adobe, Android, WebCore, WebKit2, V8, Skia, KHTML, Servo, Dart, Dartium, H.264, Safari, Gecko, Web Components, Freenode, chromestatus.com
## Video description
Answers to the top questions (listed with timecodes here http://chromium.org/blink/developer-faq#TOC-Q-A-Video) asked by the developer community about Blink. Engineering leads Darin Fisher and Eric Seidel are joined by PM Alex Komoroske and Developer Advocate Paul Irish.
Following the announcement of Blink, Google's Chrome engineering team explained that forking WebKit allows Chromium to discard legacy platform abstraction debt, tightly integrate V8 and Skia, and adopt a strict policy against vendor prefixes.
Decoupling from WebKit and WebKit2 (12:34)
Blink's split from WebKit stems from divergent architectural choices regarding multi-process architectures. Darin Fisher recounts that while Apple invited Google to integrate Chromium's multi-process model into WebKit shortly after Chrome launched, doing so presented a technically prohibitive workload due to Chromium's reliance on custom libraries. Both engineering teams subsequently focused their shared efforts on WebCore for five years. However, as Chromium's architectural requirements diverged from WebKit2, shared development became untenable.
Eric Seidel clarifies that no formal relationship exists between the Blink and WebKit teams, and Google has no active plans to backport patches. Drawing parallels to WebKit's historical split from KHTML, Seidel and Alex Komoroske observe that while patches may occasionally be adapted across projects in the short term, the codebases will naturally diverge over time, making cross-engine porting increasingly difficult.
Content Layer and Subsystem Integration (10:26)
Unlike WebKit, which required custom platform ports and extensive preprocessor macros (#ifdefs) to support different operating systems, Blink runs exclusively on Chromium's multi-process content layer. Fisher emphasizes that this virtual platform layer isolates the rendering core from direct operating system dependencies, enabling embedders to port Blink across desktop and embedded environments without fragmenting the core rendering engine.
This structural boundary couples Blink directly with Google's V8 JavaScript engine and Skia graphics library. Komoroske and Fisher note that standardizing on these dependencies allows developers to optimize internal interfaces previously constrained by WebKit's multi-engine support. As an experimental exploration, the team is evaluating whether moving Document Object Model (DOM) storage directly inside V8 can eliminate language-boundary crossing overhead between C++ WebCore and JavaScript, though Fisher stresses that this concept represents an architectural trade-off rather than a guaranteed performance gain.
Platform Cleanup and Ending Vendor Prefixes (6:33)
Blink intends to shed technical debt by pruning obsolete DOM features and legacy HTML tags, such as <isindex>, in accordance with modern HTML5 specifications. To mitigate breaking existing websites, Komoroske explains that Google uses search index crawl data to quantify real-world usage and calculate breakage risks before deprecating APIs. Fisher notes that platforms cannot continuously accumulate legacy features without degrading overall software quality.
Addressing developer friction with styling rules, Komoroske confirms that Blink has adopted a strict policy against introducing new vendor prefixes, mirroring Mozilla's approach. Experimental features will instead rely on runtime flags, and the team will not create a -blink- prefix. Inherited -webkit- prefixes will be audited individually to either standardize, un-prefix, or formally deprecate them. Fisher notes that prefixes failed their original purpose because shipping prefixed APIs still forced engines into permanent backward-compatibility support.
Deployment Timelines and Compatibility Safeguards (2:30)
Blink was enabled in Chrome Canary on the day of the announcement, with Paul Irish confirming that Chrome 28 will serve as the first official release shipping Blink on desktop and Android within approximately ten weeks. Fisher adds that development is underway within the Chromium repository to replace the legacy WebKit-based Android WebView with a Chromium- and Blink-based implementation, creating shared plumbing across the mobile browser and embeddable web views.
To prevent site-compatibility failures, Fisher confirms there are no plans to alter Chrome's User-Agent string, as many websites still rely on brittle string comparisons. The engine tokens for AppleWebKit and Safari will remain intact, with only the Chrome version number incrementing. Media decoding boundaries also remain unchanged: Seidel and Fisher clarify that video codecs like H.264 are handled by the outer browser layer, leaving Blink decoupled from specific codec implementations.
Blink represents a transition from WebKit's multi-vendor, multi-port model toward a specialized rendering engine optimized strictly for Chromium's multi-process architecture. While Google asserts that maintaining an independent engine fosters web innovation, third-party adopters must now integrate Chromium's content layer rather than treating Blink as a standalone drop-in component.
## Background
该视频由 Google for Developers 官方频道于 2013 年 4 月 4 日发布在 YouTube 上。根据页面介绍，本次问答直播由 Chrome 团队的工程负责人 Darin Fisher、Eric Seidel、产品经理 Alex Komoroske 以及开发者倡导者 Paul Irish 共同参与，旨在解答开发者社区针对 Google 刚刚宣布从 WebKit 分叉出的新渲染引擎 Blink 所提出的核心高频问题。
## TL;DR
在宣布从 WebKit 分叉出独立渲染引擎 Blink 的次日，Chrome 核心团队技术领导层就社区高度关切的架构演变与生态影响展开了详尽解答。团队澄清了与 WebKit 代码库的渐进分离关系，阐述了依托 Chromium Content Layer 多进程抽象层以彻底摆脱多平台移植碎片化的核心逻辑，并探讨了将 DOM 移入 JavaScript 虚拟机等前沿性能构想。同时，团队宣布全面转向“无厂商前缀”政策、保持 UA 字符串稳定，并强调多引擎竞争对于 Web 长期健康生态的积极价值，首个搭载 Blink 的 Chrome 28 也已进入发布周期。
## Atmosphere & style
整场直播散发着务实、严谨且充满技术底气的极客氛围，面对社区抛出的“为何当年拒绝 WebKit2”等尖锐质问，工程主创们毫不避讳、坦诚剖析历史抉择与工程权衡。四位嘉宾配合默契，既有底层架构师对性能极限和移动硬件约束的审慎克制，也有对摆脱历史包袱后轻装上阵的由衷振奋。而在探讨严肃的标准生态之余，团队穿插着对 <blink> 标签和与 Mozilla 隔窗相望的幽默调侃，使这场重磅技术分叉的答疑会显得亲切、透明且兼具温度。
## Bulletin
- [02:30](https://www.youtube.com/watch?v=TlJob8K_OwE&t=150s) Google 宣布从 WebKit 正式分叉出全新渲染引擎 Blink，首个搭载版本为 Chrome 28，预计约 10 周后推向稳定版。
- [10:26](https://www.youtube.com/watch?v=TlJob8K_OwE&t=626s) Blink 架构解耦宿主操作系统，深度绑定 Chromium 的 Content Layer、V8 引擎与 Skia 图形库，彻底终结了通过 #ifdef 宏维护多平台移植的传统做法。
- [06:33](https://www.youtube.com/watch?v=TlJob8K_OwE&t=393s) 团队宣布全面执行零厂商前缀（No vendor prefixes）政策，绝不引入 Blink 专属前缀，并通过全网搜索索引大数据评估存量前缀的安全下线路径。
- [26:40](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1600s) Blink 定位为保障当前稳定产品交付的工程实现，与 Mozilla 从零构建的实验性科研引擎 Servo 形成互补而非直接竞争。
## Key takeaways
- [01:05](https://www.youtube.com/watch?v=TlJob8K_OwE&t=65s) Blink 与 WebKit 代码库之间没有正式的合作机制，双方将各自独立演化，跨项目移植补丁的难度会随时间推移而大幅增加。
- [02:30](https://www.youtube.com/watch?v=TlJob8K_OwE&t=150s) Chrome 28 为首个搭载 Blink 的正式版本，且短期内 User-Agent 字符串将保持现有格式冻结，确保不对现有 Web 生态造成兼容性冲击。
- [04:59](https://www.youtube.com/watch?v=TlJob8K_OwE&t=299s) Blink 正在探索将 DOM 完全移入 JavaScript 虚拟机内部的长远构想，以消除 JS 与 WebCore C++ 层之间的跨边界切换性能开销。
- [06:33](https://www.youtube.com/watch?v=TlJob8K_OwE&t=393s) 团队将利用 Google 全网搜索索引的大数据分析，精准扫描并量化废弃陈旧冷门特性的风险，坚决避免破坏现有 Web 应用。
- [09:28](https://www.youtube.com/watch?v=TlJob8K_OwE&t=568s) 得益于 Chromium 的多进程沙箱架构与虚拟平台抽象层，Blink 避免了 WebKit 历史上的多平台碎片化移植困境。
- [10:26](https://www.youtube.com/watch?v=TlJob8K_OwE&t=626s) Blink 将宿主环境统一收敛至 Chromium Content Layer，使 V8 与 Skia 团队能够放开手脚开展端到端的深度性能调优。
- [13:33](https://www.youtube.com/watch?v=TlJob8K_OwE&t=813s) 当年未采纳苹果 WebKit2 架构的主因在于 Chrome 现成的成熟多进程体系与 WebKit 严重脱节，迁移改造成本过高且时间线完全错位。
- [16:46](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1006s) 基于 Chrome 构建的全新 Android WebView API 最终将正式并入 Android 系统，使移动端系统级 WebView 统一采用 Blink 底座。
- [16:46](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1006s) Dart VM 尚未合入 Chromium 主线并非架构存在技术阻碍，而是受限于 Dart 语言自身的发展规划与团队对长期维护承诺的审慎考量。
- [16:46](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1006s) Blink 团队秉承克制的工程哲学，拒绝为一个问题提供重复冗余的 API 解决方案，坚持所有新功能都必须适配严苛的移动端硬件资源约束。
- [19:24](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1164s) Google 坚信多元独立的渲染引擎能够激发行业竞争并促进行业健康发展，避免 Web 开发者被迫绑定于单一引擎的偶发怪癖。
- [21:20](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1280s) Blink 沿用原 WebKit 的 BSD 与 LGPL 等开源许可证组合，且视频编解码管线（如 H.264）由 Chromium 外部层处理，引擎内部对此完全解耦。
- [26:40](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1600s) 团队与 Mozilla 保持着频繁的技术互访与思路共享，Blink 专注于面向当下的可靠产品交付，而 Servo 则定位于激进的科研探索。
- [29:01](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1741s) 历史经验证明厂商前缀不仅没有实际价值反而造成严重平台债务，Blink 决定彻底封死任何新增私有前缀的可能性。
- [30:17](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1817s) 团队明确拒绝在 Blink 中原生重新引入 <blink> 标签或闪烁样式，建议有怀旧需求的开发者使用现代 Web Components 规范自行封装实现。
## Detailed walkthrough
### [00:08](https://www.youtube.com/watch?v=TlJob8K_OwE&t=8s) 见面会介绍与小组阵容
在 Google 正式宣布从 WebKit 分叉出新渲染引擎 Blink 的次日，Chrome 团队举办了一场问答直播，旨在解答开发者社区在过去一天中提交并投票选出的各类关键问题。Chrome 团队的开发者倡导者（Developer Advocate）Paul Irish 担任主持，并向观众介绍了来自 Chrome Web 平台团队的核心技术领导阵容：工程主管 Darin Fisher、产品经理 Alex Komoroske，以及长期担任 WebKit 核心贡献者、现为 Blink 团队成员的资深工程师 Eric Seidel。
### [01:05](https://www.youtube.com/watch?v=TlJob8K_OwE&t=65s) WebKit 与 Blink 未来的代码库关系与协作
问答环节以 Chromium 工程师 Peter Kasting 提出的三连问开场：未来 WebKit 与 Blink 代码库之间将维持怎样的关系？Chromium 移植版（Chromium port）是否会从 WebKit 代码库中移除？是否有既定的政策或工具链来确保一个代码库中的 Bug 修复和新特性能够迁移合并到另一个代码库？
针对两者的代码库关系，Eric Seidel 直言：“There's no real formal relationship between the two teams.”（两个团队之间并没有真正正式的合作关系）。他预计，虽然起初两个代码库差异尚小，双方还会共享思路甚至少量补丁，但随着时间推移，两套代码库必然会走向分道扬镳，相互移植补丁的难度也会越来越大。至于 WebKit 何时或是否清理 Chromium port，Eric 认为这完全取决于 WebKit 开源项目社区自身的决策与评估。
Alex Komoroske 则补充道，Chrome 团队长期以来都在通过 W3C 等标准组织活动、非正式技术探讨、跨项目提交 Bug 以及在彼此的问题追踪系统中交流等方式，与其他各大浏览器厂商保持合作，因此 Blink 与 WebKit 之间的协作互动并不会脱离这种行业常态。
### [02:30](https://www.youtube.com/watch?v=TlJob8K_OwE&t=150s) Blink 的发布时间表与 Android 平台过渡
针对布加勒斯特的 Mihai 及多位开发者关心的可用性问题——Blink 究竟何时进入 Canary 渠道、何时进入稳定版（Stable）、目前开发进度究竟如何，团队给出了明确的节奏与预期。Alex Komoroske 安抚开发者称，在项目最早期阶段，Blink 与 WebKit 几乎没有任何实质区别，两者是随着时间演进才逐步走向不同方向的。即使当天的 Chrome Canary 已经技术性地切换为 Blink 构建，但对普通 Web 开发者来说是完全无感知的，甚至连 User-Agent 字符串在短期内都保持不变。
针对 Android 平台的 WebKit 迁移以及 Chrome for Android 和系统原生浏览器（Stock Android Browser）的前景，Darin Fisher 明确了技术边界：无论是桌面版还是移动平台，未来的所有 Chrome 都会统一基于 Blink 运行；而原生 Android 浏览器的产品路线则依附于系统自身的产品周期。团队目前的重点是确保 Blink 能够在 Chrome 所支持的各类软硬件平台上提供卓越的 Web 渲染性能。
- **首发版本**：Chrome 28 是首个搭载 Blink 的正式版本，桌面版与 Android 版节奏一致。
- **发布节奏**：该版本当天已进入 Canary 阶段，预计在约 10 周后推送至稳定版。
- **移动端预览**：Android 用户亦可通过 Google Play 商店的 Chrome Beta 渠道体验后续集成进展。
### [04:59](https://www.youtube.com/watch?v=TlJob8K_OwE&t=299s) 架构设想：将 DOM 完全移入 JavaScript
在官方随公告发布的架构说明文档中，有一项极为引人注目的长远构想——探索将整个 DOM（文档对象模型）完全移入 JavaScript 虚拟机内部。Paul Irish 邀请技术负责人展开阐述这一设想的技术动机与深层考量。
Eric Seidel 解释了现代浏览器的性能瓶颈所在：目前 DOM 是在底层的 WebCore 中完全使用 C++ 实现的；每当网页中的 JavaScript 访问或操作 DOM 节点时，执行流程都必须跳出 JavaScript 虚拟机并跨越边界进入 WebCore 的 C++ 层，这一跨边界上下文切换存在固有的性能开销。尽管当前经过优化已经相当敏捷，但团队追求的是极致性能：“And the way to make it way faster is for your code to not ever have to leave the JavaScript virtual machine, but instead be able to access the DOM directly.”（而大幅提升速度的方法，就是让代码完全不必离开 JavaScript 虚拟机，而是能够直接访问 DOM）。
Darin Fisher 与 Alex Komoroske 补充强调，之所以称其为“疯狂的构想”（Crazy idea），是因为技术改造绝非稳赚不赔，背后牵涉极其复杂的工程权衡与优缺点评估。但分叉 Blink 的最大价值，正在于团队能够摆脱过去的架构包袱，自由调整架构边界，将心愿单上的大胆假设付诸原型验证。
### [06:33](https://www.youtube.com/watch?v=TlJob8K_OwE&t=393s) 清理历史包袱与厂商前缀策略
开发者十分关注文档中提到的“移除晦涩/冷门的 DOM 部件，为了性能与降低复杂度不惜引入向后不兼容变动”。Eric Seidel 说明这实际上顺应了现代 Web 平台的大趋势，正如 HTML5 规范积极清理了许多源自 HTML 2 或 HTML 3 时代、长达二十年无人问津的陈旧特性一样。例如历史遗留的 `<isindex>` 标签已被现代简洁标准取代，而 DOM 理论规范中存在的实体引用节点（Entity Reference Nodes）在真实世界也几乎没有实际用例。
Darin Fisher 强调团队绝不会粗暴地破坏开发者生态：“But we plan to do so very carefully, to ensure that we are not breaking or torturing web developers along the way.”（但我们计划非常谨慎地进行，以确保一路走来不会破坏网页或折磨 Web 开发者）。为了实现精准、负责任的废弃，团队通过 Google 的全网搜索索引（Search Index）对真实网页的代码使用情况进行大数据扫描与数据发布，量化评估特性下线的风险。
在厂商前缀（Vendor Prefixes）方面，Alex Komoroske 宣布 Blink 将全面转向与 Mozilla 类似的“无厂商前缀”政策（No vendor prefixes policy）：
```mermaid
flowchart TD
accTitle: Blink 厂商前缀处理与演进路径
accDescr: 展示 Blink 针对继承的历史前缀属性进行分类评估与逐步淘汰的流程图。
A["继承的历史前缀属性 (Legacy Prefixes)"] --> B{"是否有对应无前缀标准实现？"}
B -->|"是 (标准属性已可用)"| C["逐步废弃并移除 -webkit- 前缀版本"]
B -->|"否 (仍属非标准特性)"| D{"评估特性的真实价值与全网依赖"}
D -->|"具备广泛需求"| E["推向 W3C 等标准组织进行标准化"]
D -->|"无价值或低频滥用"| F["安全负责地下线与完全废弃"]
C --> G["终极目标：零厂商前缀的干净 Web 平台"]
E --> G
F --> G
```
### [09:28](https://www.youtube.com/watch?v=TlJob8K_OwE&t=568s) 避免 WebKit 协作困境与 Blink 的虚拟平台架构
针对“随着贡献者增多及移植平台扩展，Blink 是否会重蹈此前困扰 WebKit 的跨团队协作泥潭”这一犀利问题，Darin Fisher 剖析了 WebKit 过去多平台移植（Porting）所面临的架构根因。在 WebKit 体系下，每个厂商为了支持不同的操作系统或 GUI 工具包，都在底层插入了大量 OS 专有代码，导致分支逻辑碎片化严重。
而 Blink 走了一条完全不同的架构路线。得益于 Chromium 长期坚持的多进程沙箱安全架构（Sandboxed, Multi-process Architecture），渲染引擎本身已被完全剥离了对具体宿主操作系统的直接依赖。团队在历年工程实践中构建了一套高度抽象的“虚拟平台层”（Virtual Platform / Abstraction Layer），使得无论是在高性能桌面环境还是在受限的嵌入式设备上运行 Blink，几乎都不需要对渲染引擎的核心代码进行重型移植改造。这种统一的平台抽象极大降低了多系统维护的代码分歧，从根源上规避了阻碍过去 WebKit 社区高效协作的架构隐患。
### [10:26](https://www.youtube.com/watch?v=TlJob8K_OwE&t=626s) Chromium Content Layer 与跨平台模块化设计
随着 Blink 的独立，它唯一支持的宿主环境就是 Chromium 的 Content Layer（内容层），这使得整个代码库具有极高的可移植性。Darin Fisher 指出，业界已经有许多团队成功将 Chromium 的 Content Layer 作为多进程嵌入层移植到不同的操作系统，并应用于形形色色的应用程序中，而无需对 Chromium 进行大规模的 Fork（代码分叉）或打入大量补丁。团队对于未来的前景感到振奋，因为开发者不再需要用繁复的预处理指令（`#ifdef`）去“折磨”代码库，就能以全新的方式集成并参与 Blink 的开发。
Alex Komoroske 提到了 Paul Irish 不久前发表的一篇技术博客，该文详细拆解了 WebKit 复杂的层级架构，指出过去为了支持各个平台，移植者必须亲自实现大量底层接口。而在 Blink 体系下，借助 Content Layer，所有这些能力都是开箱即用的跨平台实现。Darin Fisher 进一步阐明，这并不意味着 Content Layer 是一块铁板铁壁的单一整体，它本身具备模块化特性，开发者如果不想要某些模块，完全可以将其剔除。Chromium 始终秉承的理念是通过模块化解耦，坚决摒弃通过预处理器宏来切割代码的做法。
当 Paul Irish 问及 V8 引擎和 Skia 图形库是否直接绑定在 Content Layer 中时，Darin Fisher 给予了肯定答复：Blink 将深度依赖 Skia 进行图形渲染，依赖 V8 处理 JavaScript。Alex Komoroske 和 Darin Fisher 均强调，这种明确的技术栈收敛并非限制，反而赋予了团队绝佳的机会——Skia 团队和 V8 团队对这种深度整合感到极为兴奋，因为他们终于可以放开手脚重构底层交互接口，对渲染引擎进行深度的端到端性能调优。
```mermaid
flowchart TD
accTitle: Chromium 与 Blink 架构关系
accDescr: 展示 Blink 嵌入在 Content Layer 中，并与 Skia 和 V8 引擎深度集成的架构关系。
subgraph HostApp["宿主应用程序 / 嵌入环境"]
App["各种平台应用 (无需维护大量 ifdef)"]
end
subgraph ContentLayer["Chromium Content Layer"]
CL["多进程嵌入与抽象层 (可按需增减模块)"]
subgraph EngineCore["Blink 渲染引擎"]
Blink["Blink 核心渲染逻辑"]
Skia["Skia 图形库"]
V8["V8 JavaScript 引擎"]
end
end
App --> CL
CL --> Blink
Blink --- Skia
Blink --- V8
```
- Darin Fisher 总结 Chromium 团队在工程架构上的取舍哲学：“We strive in the Chromium to modularize, as opposed to using preprocessor directives to hack up the code base.”
---
### [12:34](https://www.youtube.com/watch?v=TlJob8K_OwE&t=754s) Blink 代码是否会回流 WebKit 与两者开源关系
面对社区最关心的“Blink 的代码改动未来是否会回流（contribute back）到 WebKit 项目”这一问题，Eric Seidel 直言两者已经是完全独立的两个项目。他回顾了当年 WebKit 最初从 KHTML 分叉出来的历史：由于两者的起跑线几乎一模一样，早期确实有大量的 Patch 在两个代码库之间来回移植，他预计在 Blink 诞生初期也会出现类似的互动现象。但归根结底，它们如今拥有各自的代码仓库，Chromium 团队目前没有任何主动向 WebKit 批量同步 Patch 的计划。
Alex Komoroske 和 Eric Seidel 补充道，这两个项目都是完全开源的，社区中的任何人都拥有在它们之间移植代码的自由。Alex 坦言，随着时间推移，两个引擎在架构演进上必然会渐行渐远，代码移植的难度会成倍增加，不过在项目分离的最初阶段，互相借鉴依然相对容易。Darin Fisher 补充表示，如果社区开发者密切关注 WebKit 的提交日志，在短期内依然能看到部分 Google 工程师在向 WebKit 提交代码，但随着重心全面转移，这种现象在长期来看会逐步减少。
- Eric Seidel 明确界定了两者的关系：“They're separate projects. They are separate code bases. And we don't have any plans, currently, to be moving patches.”
---
### [13:33](https://www.youtube.com/watch?v=TlJob8K_OwE&t=813s) 多进程架构之争：为何没有采用 WebKit2
Paul Irish 抛出了一个来自社区的尖锐质问：Google 在宣布成立 Blink 时曾表示“无法适应 WebKit2 的多进程模型”是自立门户的核心诱因之一，但苹果公司的工程师却透露，在苹果动手打造 WebKit2 之前，曾提议将 Chromium 的多进程架构直接合入 WebKit 主干，却遭到了 Google 的拒绝，这究竟是怎么回事？
Darin Fisher 毫不避讳地证实了这段往事。他解释说，在 Chrome 刚刚发布后不久，苹果确实对 Chromium 研发的多进程架构表达了浓厚兴趣。但外界需要理解当时的现实：那是 Chrome 已经正式发布上线的阶段，其多进程代码库已经相当成熟，并且与 Chrome 自身的运行体系高度耦合，底层调用了大量 WebKit 体系根本没有的辅助库。面对苹果的合作意向，团队最初在技术上也觉得很兴奋，但在深入评估后发现，要想把这套架构剥离并重写以契合 WebKit，其工程量不啻于“一座难以逾越的高山”，加之双方的业务时间表完全错位，Google 最终认为在当时根本找不到一条可行的路径将该代码直接合并进 WebKit。
尽管多进程底层未能合流，但双方在随后长达五年的时间里，将精力和智慧集中投入到了能够最大化实现共赢的领域——共享 WebCore。Darin Fisher 回忆道，WebCore 是整个引擎中最敏感、最核心的阵地，涵盖了 HTML 解析、DOM 树构建以及 CSS 布局渲染等核心逻辑。双方在 WebCore 内的通力合作极为成功，极大地推动了现代 Web 标准的发展。然而，随着 Chrome 技术的演进，Chromium 团队计划对 WebCore 展开极其激进的大手术，这些变动将彻底改变 WebCore 的代码形态，而这绝非当时的 WebKit 社区所能接受。因此，分道扬镳成了无法避免的选择。Eric Seidel 对此总结道，将五年前双方错过的多进程合并与一两年前的 WebKit2 进行对比是不切实际的，它们诞生于截然不同的时间线，是为了解决不同需求而演进出的两套截然不同的架构；双方在 WebCore 成功携手合作了五年，而现在只是各自走上了不同的技术道路。
- Eric Seidel 就两个团队当年的架构分野给出了最透彻的评价：“The reality is they're very different architectures, very different answers to similar questions.”
---
### [16:46](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1006s) Android WebView 迁移 Blink 与多语言虚拟机支持（Dart）
讨论转向移动生态与多语言支持时，Paul Irish 询问了 Android 原生 WebView 对 Blink 的接纳计划。Darin Fisher 透露，只要持续追踪 Chromium 开源项目的人都能注意到，团队已经在基于 Chrome 构建全新的 Android WebView API。在时机成熟的“完满之时”（in the fullness of time），这套实现将正式集成进 Android 操作系统，届时 Blink 也会自然而然地成为 Android 原生 WebView 的底座。整个团队对此无比振奋，因为将系统级的 WebView 全面切换到 Chrome 和 Blink 的技术栈，意味着他们能够以更快的节奏修补缺陷并大幅提升其渲染性能与稳定性。
随后，现场解答了“Blink 未来是否会原生支持除 JavaScript 外的多脚本语言（例如 Dart VM）”的疑问。Darin Fisher 指出，该问题的实质指向的是 Dart VM。他澄清说，很多人以为是 WebKit 或 Blink 在技术架构上无法支持多虚拟机，但事实并非如此——实际上社区早已有了集成 Dart VM 的 Chromium 构建版本“Dartium”，负责 Dart 的工程师编写了一套对 WebKit 侵入性极小的优雅补丁，成功挂载了 Dart VM。Dart VM 之所以迟迟没有正式合入 Chromium 主线，技术架构从来不是障碍，真正的瓶颈在于 Dart 语言本身的发展时间表，团队必须等到有充分把握为 Dart VM 提供长期、稳定的维护承诺时，才会做出决策。
谈及此处，Alex Komoroske 与 Darin Fisher 强调了 Blink 项目极其严苛的工程哲学。Alex 指出，团队对待 Web 兼容性风险和新特性的实装秉持着极高的原则，任何新功能上线前都必须经过严格审视。Darin Fisher 回忆起团队中一位工程师的警醒之语：“无论我们在 Blink 里加什么，它最终都得装得进这部手机里。”因此，团队绝不会仅因为某个点子听起来很棒就贸然引入引擎。Web 平台向来饱受“为一个问题提供五六种重叠解法”的诟病，而团队的终极目标是避免日后被动地废弃（deprecate）API，绝不能在 Blink 中继续制造这类冗余和历史包袱。
- Darin Fisher 引述团队工程师的原则，强调在移动硬件约束下开发引擎的克制态度：“Whatever we do, whatever we put in Blink, it's got to fit on here.”
- Darin Fisher 批判 Web 平台的冗余通病并声明 Blink 的防范立场：“We don't want to add multiple different ways of doing the same thing. I think the web platform is famous for having multiple solutions to the same problem. And we see that as a problem.”
---
### [19:24](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1164s) 对其他基于 WebKit 浏览器生态的影响及 Google 的态度
在回答名为 spiffytech 的开发者提出的“Chromium 的这一举措将如何影响市场上大量采用 WebKit 的第三方浏览器”时，Alex Komoroske 率先给出了定调：Google 始终深信，拥有多个独立的渲染引擎不仅能激发良性竞争与技术创新，更是 Web 平台长期健康生态的基石。从宏观角度来看，Blink 的独立对整个生态系统是一场积极的变革。
Darin Fisher 从标准与开发者体验的角度展开论述。他强调，Chromium 团队会继续全力投入 Web 标准建设与跨浏览器测试套件的共享，推动所有浏览器在 Web 标准的定义上达成共识。但在这个共识之下，拥有多个独立的底层实现极为关键。如果市场上只剩下一套独大的引擎实现，Web 开发者最终将身不由己地被绑定在某个特定引擎特有的偶发怪癖（quirks）与私有实现细节上，这无论对平台的发展还是对开发者而言都极其危险。Eric Seidel 补充道，Blink 的出现为其他浏览器厂商提供了更多样化的技术选型；不过他也提醒大家，嵌入 WebKit 和嵌入 Blink 是两码事——由于 Blink 与 Chromium 的 Content Layer 紧密绑定，任何人想要嵌入 Blink，实际上都是通过嵌入 Content Layer 来实现的。
针对“这是否意味着 Google 将彻底停止向 WebKit 贡献代码”的疑虑，Eric Seidel 和 Darin Fisher 作出了明确分层：
- Eric Seidel 回顾道，Google 甚至在 Chrome 浏览器对外公开发布之前，就已经在向 WebKit 提交大量核心代码，而在 Chrome 独立发布之后，这种贡献依然持续了多年。
- Darin Fisher 澄清，Google 公司层面绝对没有下达“禁止员工向 WebKit 贡献代码”的禁令，Google 内部其他项目的员工依然拥有完全的自由去向 WebKit 提交补丁。
- Eric Seidel 明确指出分工的边界：Chromium 浏览器未来将直接搭载 Blink 上线，因此 **Chromium 团队**的工作重心将全神贯注地聚焦于 Blink。
- Alex Komoroske 阐述多元渲染引擎对 Web 的长远价值：“We fundamentally believe that having multiple rendering engines will help spur innovation, and is ultimately good for the long-term health of the web.”
### [21:20](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1280s) 开源许可证与 H.264 编解码器支持
谈及项目的代码贡献与法律许可，团队首先澄清了他们与原项目的关系。许多 Blink 团队成员长期以来都是 WebKit 的贡献者，Darin Fisher 表示他们未来仍计划向 WebKit 提交补丁，其他同事也是如此。针对社区关心的开源许可证问题，Darin Fisher 明确表示分叉并不会引发重新授权（relicensing），“这是一堆许可证的拼贴（collage of licenses）”。Eric Seidel 补充解释，由于 WebKit 历史上吸收了来自各种项目的代码，其底层主要由 BSD 和 LGPL 许可证构成。
关于 Blink 是否会继续支持 H.264 编解码器，Darin Fisher 指出这本质上是 Chrome 浏览器层面的决策，而不是渲染引擎的问题。Eric Seidel 用极具画面感的比喻解释了架构解耦：“Blink 甚至不知道有哪些编解码器的存在。它只有一个用来放视频的盒子，而 Blink 外部的机制负责把视频送进这个盒子里。因此 Blink 根本不关心、也不知道具体是什么编解码器。”
```mermaid
flowchart LR
accTitle: Video decoding architectural boundary in Blink
accDescr: Blink provides a layout box for video while external Chrome mechanisms handle the actual codec pipeline.
subgraph BlinkEngine["Blink 引擎内部"]
VBox["视频渲染占位框 (Video Box)"]
end
subgraph BrowserCore["Chrome 外部机制"]
CodecPipeline["编解码管线 (如 H.264 / WebM)"]
end
CodecPipeline -->|"投递解码帧"| VBox
```
### [22:11](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1331s) User-Agent 字符串的处理考量
社区对 User-Agent（UA）字符串中是否会出现类似 Gecko 或 KHTML 的 “Blink” 关键字十分好奇。Darin Fisher 给出明确回应：目前完全没有修改 User-Agent 字符串的计划。在现有格式中，紧随 AppleWebKit 和 Safari 后面的版本号将保持原样冻结，后续唯一会随版本迭代而改变的仅有紧跟在 Chrome 后面的版本号。
Darin Fisher 直言：“我们当然在极力抱怨 User-Agent 字符串，但也意识到对此处的任何修改都必须非常非常谨慎，因为无论你喜欢与否，人们都会对它执行各种奇奇怪怪的字符串比对。” Alex Komoroske 也附和称只要翻看任何浏览器的 UA 字符串就会发现它们简直“疯狂”。如果未来重新审视或清理 UA，讨论都会公开在 blink-dev 邮件列表上进行。Darin Fisher 回忆道，几年前曾有过成功缩减部分 UA 片段的尝试，他虽然极为渴望看到 UA 字符串迎来大刀阔斧的彻底简化，但眼下无法给出时间表，Eric Seidel 与 Paul Irish 则异口同声地点出最关键的底线：“不能搞坏网络（Don't break the web）。”
### [23:37](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1417s) 代码获取时间表与生态追踪工具
针对“何时能测试第一个 Blink 版本”的疑问，Darin Fisher 斩钉截铁地回答“就在今天（Today）”。Blink 在问答录制当天便已随 Chrome Canary 推出，Chromium 开发者也可直接自行拉取源码编译。Eric Seidel 感慨地透露，基础设施工程师们熬了通宵才促成了这一切，目前团队已经开始接受社区合并进来的补丁。
为了让习惯在 WebKit 社区盯代码的开发者无缝过渡，团队提供了全面的追踪渠道。除了 chromium.org/blink 项目主页与代码变更集链接外，Eric Seidel 建议大家加入 blink-dev@chromium.org 邮件列表以及 Freenode 上的 `#Blink` IRC 频道，并提到团队正计划像 WebKit 那样搭建基于 IRC 的自动提交机器人（commit bot）。
针对不想通读每一条 commit 的普通前端开发者，团队强调了更高效的追踪方式：
- **Chrome 测试版更新总结**：每个 Beta 版本发布时均提供汇总文章，明确列出启用了哪些新特性、哪些特性被置于 flag 实验开关后、哪些私有前缀已被弃用。
- **chromestatus.com 特性看板**：列出平台讨论中的各项特性、各浏览器的实现进度以及标准化状态。Alex Komoroske 和 Paul Irish 特别提到，该面板正向功能完备的仪表盘进化，不仅展示 Chromium 的健康状况，甚至已吸引了来自 Adobe 和 Mozilla 工程师的提交贡献。
### [26:40](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1600s) 与 Dart 语言的关系及与 Mozilla Servo 的定位差异
针对分叉是否会加速将 Dart VM 内置集成到 Chrome 中的疑问，Darin Fisher 明确表示这不会对 Dart 语言的推进产生实质影响，Eric Seidel 也指出 Dart 是独立的开源项目，底层引擎变动并不直接干涉其路线图。
对于社区关于 Blink 是否旨在正面抗衡 Mozilla 新引擎的疑问，Eric Seidel 澄清对方所指的正是 Servo 引擎。虽然 Brendan Eich 刚发表了相关博文，但 Servo 已经公开研发了很长时间。Eric Seidel 认为两者绝非直接竞争对手，Darin Fisher 也强调了本质差异：“Blink 是基于 WebKit 的演进与分叉，而 Servo 是一个从零开始完全新建的渲染引擎。”
Eric Seidel 进一步援引官方文档指出，Servo 定位是一项实验性探索，甚至可能永远不作为正式产品交付：
> “WebKit 的目标之一就是‘WebKit 不是一个科研项目’。我们的职责是交付当下的产品。而现实是，整个世界和 Web 生态系统这两种项目都需要：我们需要探索性质的、疯狂的新尝试，同时也需要能够于今天发布投产的产品。Blink 的核心就是保证当下的产品交付。”
Alex Komoroske 对 Servo 从零探索宏大设想的做法表达了由衷赞赏，Darin Fisher 也坚信两大阵营未来会有大量的思路共享。Eric Seidel 甚至指着窗外开玩笑说，他站在自己的办公室窗前就能直接看到 Mozilla 的大楼，双方团队几天前还在办公室互访交流，彼此之间是高度协同的伙伴，而非剑拔弩张的竞争对手。
### [29:01](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1741s) 彻底终结 Vendor Prefix 机制
问答最后深入探讨了存量前缀的处理策略。Alex Komoroske 重申，Blink 未来绝不会引入任何新的私有厂商前缀（vendor prefixes），但清理既有的存量前缀将是一个漫长的过程，必须谨慎评估以防破坏网络现有站点：
- **已有标准无前缀实现**：若标准版本已成熟运行多年且无前缀使用率极低，将直接安全移除对应的私有前缀。
- **未进入标准化的特性**：根据实际情况逐案分析（case-by-case），评估是彻底废弃还是继续推进其标准化流程。
Darin Fisher 剖析了摒弃厂商前缀的深层技术教训：“无论有没有前缀，只要你把东西加到平台上并发布出去，你就会被它绑死，它就变成了平台的一部分。因此添加厂商前缀只会制造出一大堆烂摊子，实际上似乎没有带来任何价值。” Eric Seidel 更是补充指出现状的荒谬性——标准组织甚至一度讨论过是否必须把带 `-webkit-` 前缀的特性直接写进 Web 规范里，这种本末倒置的困境坚定了团队的决心。Darin Fisher 与 Eric Seidel 最终郑重宣告：“绝对不会再出现 Blink 专属前缀。”
### [30:17](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1817s) 关于 `<blink>` 标签的玩笑与问答收尾
在问答环节的尾声，现场气氛变得轻松欢快。Paul Irish 笑着提到社区里出现了一个有趣的请求，有人询问新引擎 Blink 是否会顺势支持曾经臭名昭著的 CSS 属性 `text-decoration: blink`。Darin Fisher 斩钉截铁地予以否决，表示坚决不会让这种历史倒退重演：“I'm pretty sure we will not be doing that.”（我很确定我们不会这么做。）不过他也打趣补充道，或许未来可以考虑把它藏在某个实验性功能开关（flag）后面纯当娱乐。随后，Alex Komoroske 补充了一个社区内部的笑话，指出在即将到来的现代 Web Components 体系下，如果开发者真的对闪烁效果念念不忘，完全可以自己封装并实现一个 `<x-blink>` 自定义标签，而官方立场非常明确：“We will not ship the Blink tag. That's for sure.”（我们绝对不会内置发布 Blink 标签，这是肯定的。）
调侃过后，Paul Irish 代表团队对本次问答进行了总结致谢。他感谢所有提交问题以及参与投票的开发者社区成员，并希望今天的解答澄清了外界对 Blink 分支的诸多疑虑。他说明本期问答视频将会与官方已发布的其他资料一同整理发布，并建议开发者访问 chromium.org/blink，以全面了解 Blink 项目的全貌、新功能引入与实现的相关政策规范，以及涵盖更多细节的技术开发者常见问题解答（Developer FAQ）。最后，Darin Fisher 与 Paul Irish 共同向收看节目的观众致谢，正式结束了本次问答。
- **关于 `<blink>` 标签与样式的态度**：明确不会在 Blink 引擎中重新引入 `<blink>` 标签或原生 `text-decoration: blink` 属性；开发者若有怀旧需求，可通过 Web Components 自行构建 `<x-blink>` 组件。
- **后续资源与文档指引**：
- 项目官方主页：`chromium.org/blink`（包含引擎概览与特性添加策略）
- 开发者常见问题：Developer FAQ（补充解答配套的技术细节）
## Notable quotes
> [19:24](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1164s) We fundamentally believe that having multiple rendering engines will help spur innovation, and is ultimately good for the long-term health of the web. — Alex Komoroske
> [16:46](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1006s) We don't want to add multiple different ways of doing the same thing. I think the web platform is famous for having multiple solutions to the same problem. And we see that as a problem. — Darin Fisher
> [26:40](https://www.youtube.com/watch?v=TlJob8K_OwE&t=1600s) 我们需要探索性质的、疯狂的新尝试，同时也需要能够于今天发布投产的产品。Blink 的核心就是保证当下的产品交付。 — Eric Seidel
> [10:26](https://www.youtube.com/watch?v=TlJob8K_OwE&t=626s) We strive in the Chromium to modularize, as opposed to using preprocessor directives to hack up the code base. — Darin Fisher
## Mentioned
Blink, WebKit, Chromium, Google, Chrome, Paul Irish, Darin Fisher, Alex Komoroske, Eric Seidel, Peter Kasting, V8, Skia, Apple, WebKit2, Android, Dart, Dartium, Mozilla, Servo, Brendan Eich, Adobe, W3C
## Video description
Answers to the top questions (listed with timecodes here http://chromium.org/blink/developer-faq#TOC-Q-A-Video) asked by the developer community about Blink. Engineering leads Darin Fisher and Eric Seidel are joined by PM Alex Komoroske and Developer Advocate Paul Irish.
[Source](https://www.youtube.com/watch?v=TlJob8K_OwE)
Source quotes
[19:24] Alex Komoroske: We fundamentally believe that having multiple rendering engines will help spur innovation, and is ultimately good for the long-term health of the web.
[16:46] Darin Fisher: We don't want to add multiple different ways of doing the same thing. I think the web platform is famous for having multiple solutions to the same problem. And we see that as a problem.
[26:40] Eric Seidel: 我们需要探索性质的、疯狂的新尝试，同时也需要能够于今天发布投产的产品。Blink 的核心就是保证当下的产品交付。
[10:26] Darin Fisher: We strive in the Chromium to modularize, as opposed to using preprocessor directives to hack up the code base.
Source quotes
[29:01] Darin Fisher: And the reason why we don't want to do vendor prefixes anymore is because, vendor prefix or not, when you add something to the platform and you ship it, you can get stuck with it.
[17:28] Darin Fisher: I think the web platform is famous for having multiple solutions to the same problem. And we see that as a problem. We have to be responsible to not create more of those problems.
[26:40] Eric Seidel: One of WebKit's goals was WebKit is not a science project. We're about shipping a product today. And the reality is the world and the web ecosystem need both kinds. We need exploratory crazy new things. And we also need to ship something today.
[21:20] Eric Seidel: Blink doesn't know what codecs even exist. It has a box in which the video goes. And something outside of Blink makes the video go there.
Original transcript
[0:08] PAUL IRISH: Hi, and welcome to
Blink Questions Answered.
[0:12] Over the past day we've
collected hundreds of
[0:14] questions and votes from
you, getting your
[0:17] questions about Blink.
[0:19] And today we're going to be
answering all the top
[0:21] questions with this panel.
[0:23] So as a matter of
introduction, my
[0:25] name is Paul Irish.
[0:26] And I'm a developer advocate
on the Chrome team.
[0:28] And we have a whole host of
other really smart folks to
[0:32] answer these questions.
[0:33] So if you can introduce.
[0:35] DARIN FISHER: Hi, I'm
Darin Fisher.
[0:36] I'm engineering lead for the
Chrome web platform team.
[0:40] ALEX KOMOROSKE: I'm
Alex Komoroske.
[0:41] I'm a product manager on the
Chrome web platform team.
[0:45] ERIC SEIDEL: My name
is Eric Seidel.
[0:45] I'm a long time WebKit
contributor, and now a member
[0:49] of the Blink team.
[0:51] PAUL IRISH: Great.
[0:51] So we're just going to go
through from the top questions
[0:56] that were submitted and voted
up by everyone, and get some
[0:59] answers to some of the things
that everyone's wondering
[1:01] about with the new Blink
announcement.
[1:05] The first one that we have
is from Peter Kasting.
[1:08] And it's a three-parter.
[1:10] But I'll read it
out right now.
[1:12] What will be the relationship
between the WebKit and Blink
[1:15] code bases going forward?
[1:16] Will the Chromium port be
removed from WebKit?
[1:18] Is there any policy or tooling
to ensure that changes, either
[1:22] bug fixes and features,
in one code base
[1:24] migrate to the other?
[1:27] ERIC SEIDEL: I'll take that.
[1:28] There's no real formal
relationship
[1:30] between the two teams.
[1:31] I expect that they'll be
sharing ideas and some
[1:35] patches, maybe more so
in the beginning.
[1:38] In the beginning it'll be
easier to share patches.
[1:41] Over time I expect that the two
code bases will diverge,
[1:44] and will become not as easy
to share patches.
[1:49] As far as the removal of
Chromium port from WebKit,
[1:52] that's really up to the WebKit
project to figure out what
[1:55] makes sense for them.
[2:02] It'll be interesting to
see how it evolves.
[2:04] I think there's people on both
sides who care passionately
[2:06] about the web platform,
and the web platform
[2:09] implementations that are
in WebKit and in Blink.
[2:12] And people will be motivated
to share ideas.
[2:16] ALEX KOMOROSKE: I should point
out, too, that we already work
[2:19] with other browser
vendors as well.
[2:21] Standards, activities, and
informal discussions, and
[2:24] filing bugs, and commenting
on their bug databases.
[2:26] And I imagine this will
be no different.
[2:30] PAUL IRISH: Great.
[2:31] The next question is
about availability.
[2:33] A lot of people were
curious about this.
[2:36] So we got a question from Mihai
in Bucharest, and from a
[2:40] number of other people.
[2:42] When will Blink ship
on Canary?
[2:44] When will it be available
in stable?
[2:47] How far along in development
is it?
[2:49] ALEX KOMOROSKE: One thing that I
want to emphasize is that at
[2:51] the very beginning there's
really nothing
[2:54] different from WebKit.
[2:55] It's over time that they will
evolve in different
[2:57] directions.
[2:58] Technically, today's canary
will be using Bink.
[3:01] But in reality there's going
to be no difference for web
[3:03] developers, nothing that
you can even see.
[3:05] The user agent, for example,
will remain the same for the
[3:07] time being.
[3:08] PAUL IRISH: If you want,
you can test out
[3:10] today's canary build.
[3:12] Blink is in it.
[3:14] But really it's basically
the exact same
[3:17] as yesterday's canary.
[3:18] So you won't have any big
changes to deal with.
[3:24] We'll move forward.
[3:25] What is the plan for
transitioning the WebKit
[3:28] integrated in Android
to Blink look like?
[3:32] So what's the story for the
Chrome on Android and the
[3:37] stock Android browser?
[3:41] DARIN FISHER: I think the story
is very similar to the
[3:43] previous question.
[3:45] Chrome, going forward will be
using Blink instead of WebKit.
[3:49] That means Chrome,
on all platforms,
[3:52] will be using Blink.
[3:55] The second part about that, the
Android browser, that has
[3:59] to do with the product
cycle for Chrome,
[4:01] and Chrome on Android.
[4:04] As far as this team is focused
on, we're just trying to make
[4:06] sure that Blink runs really
great, and is a great web
[4:10] rendering engine for Chrome, on
all platforms where Chrome
[4:13] can be found.
[4:14] PAUL IRISH: I should point out
that Chrome and Android will
[4:18] essentially have Blink
as of version 28.
[4:23] This is the same for
Chrome on desktop.
[4:25] So 28 is the first
Chrome release.
[4:29] It's in its canary right now.
[4:31] And it'll be in stable in
about 10-ish weeks.
[4:34] Hopefully, we'll see.
[4:36] DARIN FISHER: I'm not
sure when they'll be
[4:37] pushing the next beta.
[4:41] PAUL IRISH: There's a Chrome on
Android beta via the Play
[4:43] store they can take a look at.
[4:46] Not exactly sure when
it'll be there.
[4:48] Again, don't expect
any big changes.
[4:51] It's the same code base,
for the most.
[4:59] In some of the documentation
that came out yesterday, there
[5:03] was a point around some of the
architectural changes that
[5:05] we're looking at.
[5:07] So one of them was we said, we'd
like to exploring larger
[5:11] ideas, like moving the entire
DOM into JavaScript.
[5:14] This has the potential to make
JavaScript DOM access
[5:16] dramatically faster.
[5:18] Is there anything that we
can elaborate on on
[5:20] this kind of idea?
[5:21] ERIC SEIDEL: I'm happy
to take that.
[5:22] So one of things to understand
is the Document Object Model,
[5:25] the DOM is implemented in the
part we call WebCore,
[5:28] which is all C++.
[5:29] And when you, in your JavaScript
page, access the
[5:32] DOM, your code has to leave the
JavaScript virtual machine
[5:36] and enter into WebCore.
[5:37] There's a cost of that.
[5:39] And although it's pretty
fast today, we'd like
[5:41] it to be way faster.
[5:42] And the way to make it way
faster is for your code to not
[5:45] ever have to leave the
JavaScript virtual machine,
[5:47] but instead be able to access
the DOM directly.
[5:49] And to do that we'd have to move
the DOM into JavaScript.
[5:52] And this is one of the many
crazy ideas that were
[5:56] exploring in the future
of Blink.
[5:58] DARIN FISHER: Crazy, because
it's not exactly
[6:00] an automatic win.
[6:02] There's pros and cons
to any such change.
[6:05] And we're going to explore that,
and see what kind of
[6:07] benefits we can derive and what
opportunities can be had
[6:11] from such a crazy idea that.
[6:14] ALEX KOMOROSKE: There
are a lot of ideas
[6:15] on the project page.
[6:17] We're just collecting a wish
list of things we want to look
[6:19] into and investigate
that now we can.
[6:21] Because we can change
architectural boundaries if
[6:24] necessary, and really
dream big.
[6:27] I think we're all really excited
try all these crazy
[6:30] ideas, and see which
ones work.
[6:33] PAUL IRISH: Another question
that we had--
[6:35] this is from Greg again--
something
[6:37] that was in the Docs.
[6:39] This was around removing
things.
[6:42] We had a note and there around
removing obscure parts of the
[6:46] DOM, and making backwards
incompatible changes to
[6:49] obscure parts that benefit
performance or remove
[6:52] complexity.
[6:53] What can we share around this?
[6:57] ERIC SEIDEL: I'm happy
to take that as well.
[6:58] This actually a larger trend in
the web platform right now.
[7:02] If you look at HTML5, HTML5 did
a lot of work to try to
[7:06] remove some of the old crufty
bits that were perhaps speced
[7:09] in HTML2 or 3, but haven't
been used in 20 years.
[7:12] A good example of this is the
isindex tag, which was an idea
[7:17] long ago, and has now been
replaced by a much simpler
[7:20] implementation in HTML5.
[7:22] And the same thing is true of
these things called entity
[7:24] reference nodes, which exists
technical in the DOM, but
[7:27] nobody's ever used.
[7:28] So we've been removing these
out of WebKit and out of
[7:31] Blink, as the specs have moved
forward to also remove them.
[7:35] DARIN FISHER: But we plan to
do so very carefully, to
[7:37] ensure that we are not breaking
or torturing web
[7:40] developers along the way.
[7:41] The idea is to identify the low
hanging fruit, and clean
[7:44] up the platform, if we can.
[7:47] And hopefully in a way that
moves a platform forward in a
[7:51] very positive way.
[7:52] Because over time, if you just
keep accumulating features,
[7:55] the platform suffers.
[7:57] ALEX KOMOROSKE: We've been
investigating looking at, for
[7:59] example, across the web with the
search index, and seeing
[8:03] where these different features
are being used.
[8:05] We published a few
of those results.
[8:06] We're looking into that more.
[8:07] Because that helps give us a
better lens into what features
[8:10] are actually being used, and how
much of a risk there is in
[8:13] removing them.
[8:14] Certain features, like isindex,
no one's using that.
[8:16] But other ones, it
helps figure out
[8:18] which ones you can--
[8:20] [INAUDIBLE]
[8:20] responsibly.
[8:21] DARIN FISHER: Sometimes we have
to do some work to help
[8:23] people migrate.
[8:24] We have some evangelism
work, and so on.
[8:26] Because there can be some people
stuck on an old way of
[8:29] doing something.
[8:30] And there's a new way that
would be better.
[8:34] PAUL IRISH: Some of that, taking
a look at the real
[8:36] world usage of CSS, whether
the prefix to prefix DOM
[8:41] things, we've looked into this
as a way to identify how we
[8:45] can responsibly deprecate
things like prefixed CSS
[8:48] properties as well.
[8:50] ALEX KOMOROSKE: We announced
yesterday that going forward
[8:52] we'll have a policy of no vendor
prefixes, which is
[8:54] similar to what Mozilla
is doing, and the
[8:57] policy they've adopted.
[8:59] There are a lot of legacy
prefixes for
[9:00] stuff that we've inherited.
[9:02] And over time, on a case
by case basis, we'll be
[9:05] investigating which of these
we can just deprecate the
[9:08] prefix version, because the
non-prefixed version works.
[9:11] Which ones are nonstandard?
[9:12] Should those just be
fully deprecated?
[9:13] Should they be standardized?
[9:15] And really on a case by case
basis trying to work
[9:17] through this list.
[9:18] Ultimately, sometime in the
future, getting to a point
[9:20] where hopefully there
are no prefixes.
[9:22] That'll take us some
time to get to.
[9:24] We have to do it responsibly
so we don't break stuff.
[9:28] PAUL IRISH: Next question is,
what will prevent the same
[9:31] collaborative development
difficulties that hampered
[9:33] WebKit emerging in Blink as it
gains more contributors, and
[9:36] is ported to more platforms?
[9:38] DARIN FISHER: The key comment
here is porting.
[9:41] And actually Blink will be built
on a virtual platform,
[9:48] if you will, that doesn't
require a lot of porting
[9:50] effort to bring it
to new platforms.
[9:52] You can see already that Chrome
runs on variety of
[9:54] devices, from desktop down
to embedded systems.
[9:58] And the point is that not a
lot of work is required to
[10:03] move that code base across
these different systems.
[10:06] This is all true because
Chromium's sandboxed,
[10:09] multi-process architecture
forced us to take away
[10:15] OS-specific integration
from the web platform
[10:18] implementation, from WebKit.
[10:20] So we, over the course of
time, developed this
[10:23] abstraction layer, this virtual
platform on which
[10:24] WebKit's built.
[10:26] And going forward with Blink,
that's the only platform that
[10:28] will support Blink, which means
that it will be very
[10:32] portable code base.
[10:33] We've already seen people
having plenty of success
[10:36] taking Chromium's content
layer, which is the
[10:40] multi-process embedding
layers, that it
[10:43] will enclose Blink.
[10:45] And they've taken that to many
other platforms, and used it
[10:47] in many different sorts of
applications, all without
[10:49] having to substantially fork
or add code to Chromium.
[10:56] We're really excited about the
prospects of allowing a lot of
[10:59] people to participate on Blink,
and make use of it in
[11:02] new ways, without having to
torture the code base with a
[11:05] lot of ifdefs or variations.
[11:09] ALEX KOMOROSKE: Paul, you had a
post a few weeks ago that I
[11:12] thought was amazing.
[11:13] I learned a lot from that
post, actually.
[11:14] And you talked about how there
are different layers in WebKit
[11:18] supporting them all.
[11:18] You have to bring a lot of
things to the table, every
[11:21] platform you want to run on.
[11:22] And with Blink, in with the
content layer, you get all
[11:26] this stuff just more easily.
[11:28] We don't have to implement
a special version.
[11:29] DARIN FISHER: You get a
cross-platform implementation
[11:31] of these things.
[11:32] It isn't like it's
an atomic unit.
[11:34] There is some modularity
to it.
[11:36] It allows people to subtract
modules that they don't want
[11:39] to bring with them
to the platform.
[11:40] But we strive in the Chromium
to modularize, as opposed to
[11:47] using preprocessor directives
to hack up the code base.
[11:56] PAUL IRISH: Say, for instance,
V8 and Skia-- do those come
[11:59] along with the content
layer of Chromium?
[12:01] DARIN FISHER: That's right.
[12:01] V8 and Skia are implied
by this system.
[12:05] So Blink will depend on Skia
for its graphics and V8 for
[12:08] its JavaScript engine.
[12:10] ALEX KOMOROSKE: And actually
that coupling allows us to
[12:12] potentially change those
architectural layers, they way
[12:16] those interact, and
optimize those.
[12:18] DARIN FISHER: This is a really
important point.
[12:19] I think both the Skia team and
V8 are both pretty excited
[12:23] about the opportunity to improve
the integration of
[12:26] those libraries with the
rendering engine.
[12:28] That's going to mean changes
in those interfaces.
[12:32] PAUL IRISH: Great.
[12:34] Moving on to the next question,
will the changes
[12:36] from Blink be contributed back
to the WebKit project.
[12:40] ERIC SEIDEL: They're
separate projects.
[12:41] Definitely when we forked WebKit
from KHTML, we saw a
[12:46] lot of changes that got moved
back and forth between the
[12:49] code bases.
[12:49] Because they began
so similarly.
[12:51] And I would predict that similar
effects will happen
[12:54] with Blink.
[12:56] But they are separate
projects.
[12:57] They are separate code bases.
[12:59] And we don't have any
plans, currently,
[13:02] to be moving patches.
[13:04] ALEX KOMOROSKE: But they're
both open source.
[13:06] ERIC SEIDEL: They're
both open source.
[13:06] And anybody can do that.
[13:08] ALEX KOMOROSKE: Over time, as
they evolve in different
[13:10] directions, that will get
harder and harder to do.
[13:12] But in the beginning especially,
hopefully it won't
[13:14] be too hard for sharing
back and forth.
[13:17] DARIN FISHER: I think those
watching the change logs and
[13:20] will see probably see some
Googlers contributing some
[13:24] changes to WebKit, certainly
in the near term.
[13:27] I think over time that will
probably diminish.
[13:33] PAUL IRISH: The next question,
Google said problems living
[13:35] with the WebKit2 multi-process
model was a prime reason to
[13:38] create Blink.
[13:39] But Apple engineers say they
asked to integrate Chromium's
[13:42] multi-process into WebKit prior
to creating WebKit2 and
[13:44] were refused.
[13:46] What gives?
[13:50] DARIN FISHER: It's true that
Apple, shortly after launching
[13:53] Chrome, Apple expressed interest
in our multi-process
[13:57] layer that we had developed.
[13:59] I think it's important to
understand that that code
[14:01] base, the multi-process
layer was fairly
[14:04] mature at that point.
[14:05] We had launched Chrome.
[14:07] We had developed a system that
was very coupled into Chrome's
[14:12] system, it's way
of doing stuff.
[14:16] It leveraged libraries that
WebKit didn't use, and so on.
[14:19] And so for us we viewed that
opportunity to work with Apple
[14:24] on the multi-process code as--
actually that sounded quite
[14:28] exciting to us.
[14:29] However, we saw that as a
mountain of work, a large,
[14:34] technically challenging
engineering project for us.
[14:40] Perhaps it's a matter of the
timelines not being favorable.
[14:44] But we just didn't see a path
forward that allowed us to
[14:47] contribute that code
to WebKit.
[14:51] ALEX KOMOROSKE: But overall I
think what the teams ended up
[14:54] doing was collaborating really
effectively within WebCore.
[14:57] DARIN FISHER: We focused on
where we can maximize the
[15:00] benefits of working together
with Apple.
[15:02] And that was sharing WebCore.
[15:04] The parts that is a very
sensitive part of the code
[15:06] base, where HTML is parsed,
where the DOM is constructed,
[15:10] where CSS is used to render that
DOM into the web pages as
[15:14] we know it.
[15:15] That part of the web, there was
so much value in sharing
[15:18] that code that we did our best
to streamline or our way of
[15:25] using WebKit, so that we could
get as many developers focused
[15:28] on WebCore as possible, and
working with Apple.
[15:30] And I think it's been
very successful.
[15:34] Going forward, I think, as we
hinted to, there's some
[15:37] significant changes that we want
to make that we feel will
[15:44] affect the shape of WebCore in
ways that the WebCore project,
[15:52] WebKit, might not be
ready to receive.
[15:53] So we don't want to keep
on constraints.
[15:58] That's what these us to
where we are today.
[16:01] Do you guys have anything
to add?
[16:03] ERIC SEIDEL: The reality is
they're just very different
[16:06] architectures to serve
very different needs.
[16:09] And the question of whether
WebKit could have adopted our
[16:13] model, or whether we would
adopt their model are
[16:18] questions comparing different
timelines.
[16:20] One was five years ago.
[16:21] One was a year or two ago.
[16:24] So they're almost
incomparable.
[16:25] But the reality is they're very
different architectures,
[16:27] very different answers
to similar questions.
[16:31] And we chose different paths.
[16:33] And we successfully collaborated
in the WebKit
[16:35] project for the last
five years.
[16:37] And it's been great.
[16:38] And I think we'll continue
to collaborate
[16:39] with the WebKit project.
[16:41] But we've chosen different
paths.
[16:46] PAUL IRISH: Is there anything
that we can say around
[16:49] Android's web view
implementation and its
[16:52] adopting Blink?
[16:55] DARIN FISHER: Those following
along in the Chromium project
[16:57] can see that there's been
development of Android web
[17:01] view API on top of Chrome.
[17:04] In the fullness of time, when
that comes to Android, then
[17:06] Blink will come to Android.
[17:08] I'm excited about that.
[17:09] I think it's great from our
point of view of our team to
[17:14] help enable the use of web view
to be based on Chrome.
[17:18] So that we can help
make it better.
[17:20] And have it be based on
Blink means we can
[17:22] help make it be better.
[17:23] I'm excited about that.
[17:25] PAUL IRISH: Absolutely.
[17:28] Will Blink be able to support
multiple scripting languages?
[17:36] DARIN FISHER: Sorry, I think
our plan going forward--
[17:39] I think this is a reference
to Dart, perhaps?
[17:41] The Dart VM.
[17:45] It's important to understand
that even today, you can go
[17:49] and get Dartium, which is
a build of Chromium,
[17:51] uses the Dart VM.
[17:53] And the engineers working on
that project have developed a
[17:56] patch that allowed them to add
the Dart VM to WebKit in a way
[18:00] that wasn't terribly disruptive
to WebKit.
[18:03] The reason why Dart VM is not
in Chromium today doesn't
[18:07] really have to do with whether
or not WebKit supports or
[18:11] Blink supports multiple VMs.
[18:12] It has a lot more to do with
the timeline for the Dart
[18:15] itself, and getting to the point
where we feel like we
[18:18] can make a long term-- or should
make a long term--
[18:20] commitment to the Dart VM.
[18:23] ALEX KOMOROSKE: We have very
strong principles, with Blink
[18:25] especially, about compatibility
risk, and making
[18:27] sure that we responsibly
ship new features.
[18:31] These are things that we are
going to hold all features up
[18:33] to as we decide whether
or not to ship them.
[18:35] DARIN FISHER: I think somebody
made a really good point.
[18:37] I forget who it was.
[18:38] Maybe one of the other engineers
on our team.
[18:40] He said, whatever we do,
whatever we put in Blink, it's
[18:42] got to fit on here.
[18:44] And so we can't just put
everything in there just
[18:46] because it seems like
a good idea.
[18:48] We have to validate that.
[18:49] And be confident that we can
stick with that decision, make
[18:52] a long term commitment.
[18:53] And build this platform
responsibly.
[18:55] We don't want to have--
[18:59] this relates to our
whole strategy
[19:01] around deprecating APIs.
[19:02] We don't want to be in a
situation where we have to
[19:04] deprecate API.
[19:05] So we don't want to add multiple
different ways of
[19:08] doing the same thing.
[19:09] I think the web platform is
famous for having multiple
[19:12] solutions to the same problem.
[19:14] And we see that as a problem.
[19:17] We have to be responsible
to not create
[19:19] more of those problems.
[19:24] PAUL IRISH: This is a question
from spiffytech.
[19:25] How does the Chromium team
expect this will affect the
[19:28] myriad of other browsers that
have adopted WebKit.
[19:32] ALEX KOMOROSKE: I should say,
too, one thing to start off.
[19:35] We fundamentally believe that
having multiple rendering
[19:37] engines will help spur
innovation, and is ultimately
[19:40] good for the long-term
health of the web.
[19:42] And so in that respect, I
think it's actually very
[19:44] healthy for the whole
ecosystem.
[19:47] So just to get started
with that.
[19:50] DARIN FISHER: As a team, we're
really focused on web
[19:51] standards, and sharing tasks,
and helping this ecosystem of
[19:59] browsers all agree on what the
web platform should be.
[20:03] But having multiple
[20:04] implementations is really valuable.
[20:07] Without that, developers are
stuck maybe with the quirks of
[20:12] a particular engine.
[20:14] And that's not healthy
for the platform.
[20:17] It's not great for developers,
as far as we can tell.
[20:21] ERIC SEIDEL: I hope, if anything
it just gives other
[20:23] browsers choice.
[20:27] Embedding WebKit is not
comparable, really, to
[20:30] embedding Blink.
[20:30] Because Blink requires the
Chromium content layer.
[20:34] So you would embed the Chromium
content layer if you
[20:36] wanted to embed Blink.
[20:39] But it just gives you choice.
[20:44] PAUL IRISH: I think
we covered this.
[20:46] Does this mean that Google stops
contributions to WebKit?
[20:50] ERIC SEIDEL: Google contributed
WebKit before
[20:54] Chrome was announced.
[20:54] And I expect that Google will
continue to contribute after.
[20:57] DARIN FISHER: I think is
important to say that, as
[21:01] Google, we're not telling
people they shouldn't
[21:03] contribute to WebKit.
[21:04] We're just telling them that,
feel free to focus on Blink.
[21:10] ERIC SEIDEL: Chromium is
going to ship Blink.
[21:13] And so the Chromium team
is focused on Blink.
[21:18] But that doesn't mean that other
parts of Google, or even
[21:20] parts of the Blink team--
[21:21] some of us are long time
WebKit contributors.
[21:24] I plan to post patches
to WebKit.
[21:26] I expect other of my
colleagues do too.
[21:31] PAUL IRISH: What open source
license will Blink have?
[21:33] Will it continue to support
the H.264 codec?
[21:35] DARIN FISHER: There's no
relicensing happening as part
[21:37] of this fork.
[21:39] PAUL IRISH: What's the--
[21:40] DARIN FISHER: It's a collage
of licenses.
[21:42] ALEX KOMOROSKE: A collage--
that's a good
[21:42] way of putting it.
[21:44] DARIN FISHER: The history of
WebKit is that it's absorbed
[21:46] code from a variety
of projects.
[21:47] I think a lot of it is BSD.
[21:49] ERIC SEIDEL: BSD and LGPL.
[21:51] DARIN FISHER: Will it continue
to support the H.264 codec?
[21:54] That's really more of
a Chrome question.
[21:56] ERIC SEIDEL: Blink doesn't know
what codecs even exist.
[22:00] It has a box in which
the video goes.
[22:03] And something outside of Blink
makes the video go there.
[22:06] So Blink doesn't care or know.
[22:11] PAUL IRISH: We saw a lot of
questions about this.
[22:13] People are curious about
the user-agent string.
[22:17] Will we see a Blink keyword in
the user-agent string, like
[22:20] KHTML, like Gecko?
[22:21] DARIN FISHER: We have
no plans to change
[22:24] the user-agent string.
[22:25] And going forward, in fact,
there's a version number after
[22:29] Apple WebKit and Safari.
[22:32] At this point we have no plans
to change that number.
[22:35] What will change, going forward,
is just to the number
[22:37] after Chrome.
[22:39] We, of course, lament the
use-agent string profusely.
[22:44] But we also see that any changes
there have to be
[22:47] handled very, very carefully.
[22:49] Because, like it or not,
people do all kinds of
[22:52] interesting string compares
against it.
[22:55] ALEX KOMOROSKE: As you can tell
from looking at anyone's
[22:56] user-agent string,
they're crazy.
[22:59] I should say, too, this is the
kind of thing that ultimately,
[23:02] if we revisit this--
[23:03] I'm sure at some point we will--
will be doing it on
[23:05] blink-dev, the open
mailing list.
[23:07] And this will be definitely
discussion that we can take
[23:09] care of for you if
we come to it.
[23:10] DARIN FISHER: I think it was a
couple years ago that there
[23:13] was a successful effort to trim
out a few bits of the
[23:17] user-agent strings.
[23:19] Certainly be looking
for opportunities.
[23:21] I would love to see this
user-agent string be
[23:25] simplified radically.
[23:26] But it's hard to say when
or if that will happen.
[23:32] ERIC SEIDEL: Just don't
want to break the web.
[23:34] PAUL IRISH: Don't
break the web.
[23:37] When we'll be able to test
the first version Blink?
[23:42] Again this is available--
[23:43] DARIN FISHER: Today.
[23:43] PAUL IRISH: Blink is available
in Chrome Canary as of today.
[23:46] DARIN FISHER: And you can
build it yourself.
[23:47] This question was asking about
Blink in Chromium as well.
[23:50] You can just build
it yourself.
[23:52] ERIC SEIDEL: We had some
tireless infrastructure
[23:53] engineers who stayed up all
night making that true.
[23:56] ALEX KOMOROSKE: I was watching
blink-dev this morning.
[23:57] I think people succeed in
building it, correct?
[24:00] ERIC SEIDEL: Yes.
[24:01] ALEX KOMOROSKE: So at this
point we're focusing--
[24:02] ERIC SEIDEL: We have taken
patches already.
[24:04] ALEX KOMOROSKE: Great.
[24:06] ERIC SEIDEL: Blink is up
and running today.
[24:07] You can build it today.
[24:08] And I believe the Chromium
canary tomorrow is likely to
[24:12] have Blink in it.
[24:15] PAUL IRISH: Another thing I
wanted to ask about this, a
[24:22] lot of people are used to
watching change that's coming
[24:24] on the WebKit side.
[24:26] To do the same in Blink,
we have a similar
[24:29] way of doing that.
[24:30] ERIC SEIDEL: We do have URLs.
[24:30] I don't know them off
the top of my head.
[24:32] ALEX KOMOROSKE: We do.
[24:33] And I think it's on
the project page.
[24:35] Our goal is for everyone to be
able to watch this, and watch
[24:37] all the discussions and
bugs, and everything.
[24:40] So if there is something where
it's hard to follow along, we
[24:42] want to make that easier
for people.
[24:44] ERIC SEIDEL: The easy way to
answer that is to join
[24:45] blink-dev@chromium.org,
or to join the
[24:48] #Blink channel on Freenode.
[24:51] We've also talked about having
an IRC-based commit bot, just
[24:55] like the WebKit project does,
where it tells you what the
[24:57] commits as they come in.
[24:59] But that's the way to answer
that question, is to join one
[25:01] of our mailing lists or IRC.
[25:03] PAUL IRISH: And all that
information is available on
[25:04] chromium.org/blink, where you
can see our current mailing
[25:07] lists, a link to where all the
change sets are coming in,
[25:11] where you can browse them,
and everything else.
[25:13] ALEX KOMOROSKE: One thing too,
watching the change sets takes
[25:17] a lot of effort for a lot
of web developers.
[25:18] And one thing that we're doing
is, especially recently, we're
[25:22] getting better at having
summary posts.
[25:24] And so we do that for every beta
release now for Chrome.
[25:28] Those summarize what things
we've enabled, which things
[25:31] are now behind a flag, which
prefixes we've deprecated.
[25:35] That's a great way for web
developers to follow along,
[25:37] where you don't have to be
reading every single commit
[25:40] that's going through.
[25:41] And chromestatus.com
is also great.
[25:42] We're going to be--
[25:43] Max and Eric were just
talking on blink-dev.
[25:45] They have plans to make that
into more of a full future
[25:47] dashboard which is
really cool.
[25:49] PAUL IRISH: Chromestatus.com
lists out all the various
[25:52] features of the platform that
are in discussion these days,
[25:56] lists out what their
implementation status is, and
[26:00] also what their standardization
status is
[26:02] across the browser ecosystem.
[26:03] ALEX KOMOROSKE: I
love watching.
[26:04] If you haven't looked at it,
you should look at it.
[26:05] It's really interesting
to get a snapshot.
[26:08] DARIN FISHER: We all had this
idea in our head of what it
[26:10] might look like.
[26:11] But to actually see it.
[26:12] ALEX KOMOROSKE: Oh wow,
it's very interesting.
[26:14] PAUL IRISH: It's a great
snapshot of the web ecosystem
[26:17] in one view.
[26:18] And we've already been getting
some great contributions from
[26:20] Adobe over the past two days.
[26:23] ALEX KOMOROSKE: And
others, as well.
[26:23] I think we got a few guys
from Mozilla also
[26:26] helped us as well.
[26:27] The goal is to have that be a
snapshot of the health, the
[26:32] state, of the web ecosystem.
[26:33] Specifically Chromium, but over
time it could be for the
[26:36] whole web ecosystem.
[26:36] I think that's cool.
[26:38] We'll see.
[26:40] PAUL IRISH: Next question.
[26:42] How will this impacts Dart
language's process?
[26:45] Can we expect a Dart
VM to be integrated
[26:47] into Chrome as a result?
[26:49] DARIN FISHER: I already
answered the question.
[26:50] But I think it doesn't really
impact Dart language at all.
[26:56] ERIC SEIDEL: Dart's a separate
open source project.
[26:58] I don't think changes
to our open source
[27:00] really affect them directly.
[27:04] PAUL IRISH: When we get our
hands on Blink code?
[27:07] Again, today.
[27:10] Yesterday.
[27:11] We're good.
[27:13] Will this be a direct competitor
against Mozilla's
[27:16] new engine?
[27:17] Is co-working with Mozilla
out of the question?
[27:20] ERIC SEIDEL: The engine I
believe they mean is Servo,
[27:22] which although Brendan posted
about it yesterday, it's been
[27:25] in the public for a long time.
[27:27] ALEX KOMOROSKE: I remember
design docs
[27:28] about that a year ago.
[27:30] ERIC SEIDEL: I've been following
it for a while.
[27:31] It's very, very cool
what they're doing.
[27:33] ALEX KOMOROSKE: Really
cool ideas.
[27:34] ERIC SEIDEL: But I don't see
Blink as really a direct
[27:37] competitor.
[27:38] DARIN FISHER: Blink is an
iteration from WebKit.
[27:40] It's a fork of WebKit.
[27:42] Servo is a new rendering engine
[27:45] constructed from scratch.
[27:46] ERIC SEIDEL: According to
their docs, it's an
[27:47] experiment.
[27:48] The docs say that they may
not actually ever ship.
[27:51] So that's a very different kind
of project then Blink or
[27:55] WebKit, which is
really about--
[27:57] ALEX KOMOROSKE: A shipping
product.
[27:59] ERIC SEIDEL: Yeah, it's
about an iteration.
[28:00] One of WebKit's goals
was WebKit is
[28:03] not a science project.
[28:04] We're about shipping
a product today.
[28:06] And the reality is the world
and the web ecosystem need
[28:10] both kinds.
[28:11] We need exploratory
crazy new things.
[28:13] And we also need to ship
something today.
[28:16] And Blink is about
shipping today.
[28:17] ALEX KOMOROSKE: I think we're
really excited to see some of
[28:19] those ideas they're trying.
[28:20] Because we're trying to dream
big with our wish list of
[28:23] things to try.
[28:23] They're dreaming even bigger.
[28:24] Because they're building
a new one from scratch.
[28:26] ERIC SEIDEL: Which is amazing.
[28:27] ALEX KOMOROSKE: And so that
will be really cool to see
[28:28] which of those really big ideas
work, and which ones--
[28:30] DARIN FISHER: I'm sure there
will be a lot of idea sharing.
[28:32] ALEX KOMOROSKE: Absolutely.
[28:33] ERIC SEIDEL: And I can
see the Mozilla
[28:34] offices from my window.
[28:37] And we talk to Mozilla guys
with some frequency.
[28:40] And I think of them as very
cooperative, not competitors.
[28:46] DARIN FISHER: Do they know
you can see them?
[28:49] ERIC SEIDEL: I'm not sure.
[28:50] PAUL IRISH: The buildings are
right next to each other.
[28:50] ERIC SEIDEL: The buildings are
right next to each other.
[28:52] ALEX KOMOROSKE: Actually we
discussed this with some folks
[28:54] from Mozilla.
[28:54] They were visiting a few days
ago in the offices.
[28:57] We talked about the fact
that we could see them.
[29:01] PAUL IRISH: So the question
is about vendor prefixes.
[29:05] When will the existing
vendor prefixes in
[29:07] Blink be phased out?
[29:08] ALEX KOMOROSKE: I think I
already touched on this as
[29:10] part of an earlier question.
[29:12] Again, going forward, no
new vendor prefixes.
[29:15] But course there are
a number of legacy
[29:16] ones that we've inherited.
[29:17] DARIN FISHER: It could
take a long time to--
[29:19] ALEX KOMOROSKE: It could
take a long time.
[29:20] Because we want to do
it responsibly.
[29:21] Want to figure out-- we don't
want to break the web.
[29:23] So some of them are, there's
been the un-prefixed version
[29:27] for years and years and years.
[29:28] And no one's using the
prefix version.
[29:30] Go ahead and take that out.
[29:31] Other ones are things that
were never standardized.
[29:33] And we want to either figure
out, should we
[29:35] just deprecate these?
[29:36] Or should we take these
to standardization?
[29:39] But it's going to be a
case by case basis.
[29:40] DARIN FISHER: I think this
really hits on the point.
[29:43] And the reason why we don't
want to do vendor prefixes
[29:45] anymore is because, vendor
prefix or not, when you add
[29:48] something to the platform
and you ship it, you can
[29:51] get stuck with it.
[29:52] And it becomes part
of the platform.
[29:53] And so adding vendor prefixes
just makes a big old mess.
[29:58] It doesn't actually seem
to add any value.
[30:00] ERIC SEIDEL: Standards bodies
have even discussed the idea
[30:03] of needing to standardize WebKit
prefixed features,
[30:07] which is crazy to me.
[30:08] But may need to happen
if we fail to be
[30:11] able to remove these.
[30:12] ALEX KOMOROSKE: It's crazy.
[30:13] Hopefully it doesn't
come to that.
[30:14] DARIN FISHER: So there will
be no Blink prefix.
[30:16] ERIC SEIDEL: There will
be no Blink prefix.
[30:17] The madness must stop.
[30:20] PAUL IRISH: I saw a request,
actually, that we would maybe
[30:23] support -blink
text-decoration-blink.
[30:30] DARIN FISHER: I'm pretty sure
we will not be doing that.
[30:34] Maybe behind an enable
flag, just for fun.
[30:37] ALEX KOMOROSKE: Someone
was joking--
[30:38] I forget who it was--
[30:40] joking that with web components
actually someone
[30:42] could make an x-blink if they
really wanted to, their own
[30:45] version of it.
[30:48] We will not ship
the Blink tag.
[30:50] That's for sure.
[30:51] PAUL IRISH: I think that
can wrap it up for now.
[30:53] I appreciate everyone
for submitting
[30:55] questions, voting them up.
[30:57] Hope we answered a lot
of your questions.
[30:59] We'll be posting this video,
along with our
[31:02] content already out there.
[31:04] So if you haven't checked it
out, chromium.org/blink gives
[31:07] an overview of the entire
project, our policies towards
[31:11] adding features.
[31:13] And then the Developer FAQ
answers a lot of other
[31:15] questions that go along
with these ones.
[31:18] So I encourage you to
check that out.
[31:19] And I think that'll
wrap it up.
[31:21] DARIN FISHER: Thank you.
[31:22] PAUL IRISH: Thanks guys, very
much, for joining us.
