Blink: A rendering engine for the Chromium project


Google just announced it’ll fork Webkit for use with Chrome/Chromium as it has become too difficult to add features to it as Chrome uses quite a different multi-process architecture than other WebKit-based browsers:

When Chromium started, our goal was to change as little of WebKit as possible, easing integration with the WebKit codebase. With Blink we are excited to make large-scale architectural changes to the code, without having to worry about breaking other consumers of WebKit.

When Opera announced they’re dropping Presto in favor of Webkit, they actually meant Blink (src).

Blink →
Blink Announcement →

What is/isn’t Webkit?


Especially with the news that Opera has moved to WebKit, we have a lot of WebKit browsers out there, but its pretty hard to know what they share and where they part ways. So let’s take a moment to understand some things: What is WebKit? What isn’t WebKit? How is WebKit used by WebKit-based browsers? Why are all WebKits not the same?

Turns out there’s a truckload of things that are NOT shared between Webkit ports. Who’d’ve thunk?

Webkit for Developers →

Opera about to drop Presto in favor of Webkit


The writings were on the wall with Opera Ice but now it’s official: Opera will move to Webkit entirely:

To provide a leading browser on Android and iOS, this year Opera will make a gradual transition to the WebKit engine, as well as Chromium, for most of its upcoming versions of browsers for smartphones and computers.

Håkon Wium Lie’s (Opera’s CTO) reasoning:

It makes more sense to have our experts working with the open source communities to further improve WebKit and Chromium, rather than developing our own rendering engine further. Opera will contribute to the WebKit and Chromium projects, and we have already submitted our first set of patches: to improve multi-column layout.

Logic move, yet I do hope we won’t end up with only 1 rendering engine in the end (history better not be repeating itself).

Opera gears up at 300 million users →

iOS WebKit browsers and auto-zooming form controls

One thing about iOS browsers that can be pretty frustrating, both as a developer and as a user, is when you open a site on an iPhone or iPod Touch (not iPad) and want to enter some text in a text field or pick an option from a select menu. Very often the browser will automatically zoom in on the entire page a little when you tap the form control.

Roger Johansson found a way to prevent this kind of behavior

iOS WebKit browsers and auto-zooming form controls →

Opera Mobile Emulator with support for (some) -webkit vendor prefixes

Opera, along with Mozilla, announced at a CSS Working Group meeting that we would support some -webkit prefixes. This is because through our site compatibility work, we have experienced that many authors of (especially mobile) sites only use -webkit prefixed CSS, thereby ignoring other vendor prefixes and not even including an unprefixed equivalent. This leads to a reduced user experience on Opera and Firefox, which don’t receive the same shiny effects such as transitions, gradients and the like, even if the browser supported those effects.

They’ve made some beta (labs) builds of their mobile emulator supporting -webkit prefixes.

Opera Mobile Emulator Labs Builds →
Opera Mobile Emulator Labs supported -webkit properties →

Be sure to also read Faruk Ates’ two posts on the the topic.

CSS :nth-letter()

Adobe is working on implementing :nth-letter() in Webkit:

The desired syntax was :nth-letter(), where the argument would (ideally) take the same values that :nth-child() can (e.g, a simple index, even/odd, or an expression like 2n+4).

This code:

<p id="sentence">My fourth letter is awesome.</p>
#sentence:nth-letter(3) {
    color: red;
    font-family: "Comic Sans MS";
    font-size: 3em;
    font-weight: bold;

Results in this:

Whenever a final implementation lands, along with :nth-word() and the like, I guess we can say goodbye to lettering.js

Adobe WebKit Hackathon Summary →