I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

Blink

So Google created Blink, the new rendering engine for Chrome and Opera. What exactly is going on, and what will the consequences be?

Here are some notable sources on Blink that I used for this overview:

• Blink homepage and developer FAQ.
• Chromium feature dashboard, where you can see which new features are going to be added. Can use an interface upgrade; right now it’s hard to read.
• Alex Russell on Blink.
• Jake Archibald on Blink.
• Bruce Lawson on Opera’s adoption of Blink.

In addition to this information, Peter Beverloo was kind enough to send me some more by email.

What is Blink?

Blink is a new rendering engine, which means that it won’t interpret CSS and JavaScript quite the same as WebKit (or Gecko or Trident, for that matter). It will power all browsers that use Chromium, Google’s open source browser.

Blink has been forked from WebKit, which means that right now it’s almost the same as WebKit. Still, WebKit itself is not a singular entity; as my research showed time and again, one WebKit-based browser does not support exactly the same CSS and JavaScript as another. Right now it’s safe to see Blink as a kind-of WebKit.

That will change in the future. From now on, WebKit and Blink will proceed along different paths, with different goals and different supported features. At the moment code sharing between Blink and WebKit is still possible, but over time this will become less easy due to increasing differences between the two.

So Blink is a WebKit version right now, but will move away from WebKit over time, just like any fork does.

Why Blink?

Google wasn’t happy with the lack of progress in the WebKit project. This lack is mostly caused because the actual WebKit rendering engine is intertwined with implementation details that are only important for one platform — and the number of supported platforms is growing, especially in the mobile world.

Therefore Google decided to remove platform-specific code from WebKit, re-vamp the security model, and make a few other changes that will allow for quicker progress in CSS and JavaScript support.

If you have already decided Google is Evil you will not believe this explanation.

Which browsers will use Blink?

Blink has been built on top of Chromium, Google’s open-source browser. Chrome uses Chromium, as does the Yandex browser. Opera will start doing the same from version 14 on. Therefore all these browsers will use Blink in the future.

Chrome 28 will be the first stable release to use Blink; earlier versions will use WebKit. Opera and Yandex will start using Blink whenever they start using Chromium 28.

Currently Chromium is available for Windows, Mac, desktop Linux, and Android. It seems unlikely Google will port it any further, but others could.

An important Chromium component is Skia, the drawing engine. BlackBerry already ported it, which means it’s one step closer to implementing Chromium than other WebKit users. Whether BlackBerry, or anyone else, will actually make the switch is a political question as much as a technical one.

It’s theoretically possible to use Blink without Chromium, but there are so many dependencies that it’s unlikely this will ever happen.

What will change for me as a web developer?

Right now, nothing will change for web developers. The change-over from WebKit to Blink will be imperceptible — even the browser’s UA string will not change in the near future. Sure, you must test your sites in Chrome and Safari, as well as Opera, IE, Firefox, a bunch of mobile WebKits, and so on. But you were already doing that — weren’t you?

One change I rather like is Blink’s approach of vendor prefixes, which mirrors Firefox’s. It has copied all currently-existing -webkit- prefixes from WebKit, but will not add any new ones and will gradually remove the old ones when it becomes safe to do so. Instead of prefixes it will use flags: if you want to enable an experimental feature, set the appropriate flag in about:flags. (Incidentally, this means that experimental CSS features that would be prefixed are not available to the average user, who won’t set any flags.)

What about interoperable implementations?

It is W3C’s stated policy that two interoperable implementations are required for any new standard. I worried about this when Presto died and the number of rendering engines was brought down to three.

Now the number of rendering engines goes back up to four, and any WebKit feature is automagically supported by two interoperable implementations: WebKit and Blink.

Is Google Evil?

But ... but ... isn’t this a cynical move? Isn’t the openness stuff all a sham? Doesn’t Google simply want to deny a modern rendering engine to Apple and lock other Chromium-using browser vendors in?

If you wish to believe the Chrome team is acting cynically here I can’t stop you. I don’t believe it myself, though.

Sure, there is a political compoment to all of this. Google would like other browser vendors to switch from WebKit to Blink, and may exert some pressure.

Also, Google’s engineers will no longer contribute to WebKit, and other WebKit users will start to feel the pinch in another few months. Still, it’s theoretically possible that Apple and BlackBerry and Samsung and the rest take over where Google left off. And if they don’t ... what does that say about whom?

Besides, Google gave us a tool to measure its evilness: the compatibility section of the Blink homepage. Basically, a feature will be added if there’s strong browser support, or a nearly-finished spec, or moderate browser support PLUS a working draft.

This policy is eminently checkable: as soon as we see features appear that are not in other browsers and also not specified, we know that Google has gone over to the dark side. In the absence of such features we should conclude that Google’s evilness is not proven.

What about fragmentation?

As to the idea that Blink will increase fragmentation on the web: I don’t see that happening.

Chrome’s current WebKit implementation is different from everybody else’s (including Android WebKit’s), and the new rendering engine doesn’t change that.

Blink-based browsers will be more alike than WebKit-based browsers. Use of Chromium is a de-facto requirement for using Blink, and that standardises a lot of additional tasks such as networking and drawing.

In the WebKit-based browsers these tasks were up to specific components that individual browser vendors had to write (and that were partly in WebKit itself). A lot of differences between WebKits come from this source, and Blink will be much less vulnerable. Besides, Google has a vested interest in keeping the various Chromium ports aligned.

So I expect Chrome and Opera to converge significantly, which will actually decrease fragmentation. And if more browser vendors switch to Blink, fragmentation will decrease even more.

Less fragmentation means more unification, which implies quasi-dictatorial powers, no matter how enlightened, for one company or group. The problem is that Google critics seem to want neither, and that’s impossible. You can’t simultaneously oppose fragmentation and unification. You must choose one of the two to rail against.

Blink

So all in all I’m positive about this change. It’s likely that Blink will indeed speed up progress, as the Chrome team claims, it will not increase fragmentation, and little will change for web developers in the short run. What’s not to like?

One thing, though: the Blink team has a moral obligation to implement text-decoration: blink.

Here are some more notes and links.