What Google’s WebKit Fork Means for the Web and Web Developers
If you were secretly hoping that all web browsers would one day give up and adopt the WebKit rendering engine, we’ve got some bad news for you — Google just crushed those dreams.
Google has announced it is forking the WebKit rendering engine to create Blink, a new rendering engine for all Chromium-based web browsers — notably Chrome, Chromium, Opera and their mobile counterparts.
That means web developers will soon be back to testing their sites in both Chrome and Safari. Of course, as has been pointed out in the past, there have always been enough significant differences between the two that you should have been testing in both anyway.
Among the good news in the announcement is Google’s decision to not use CSS prefixes for new features. Instead Blink will follow Firefox’s lead and use flags to enable experimental features. That means developers can test and use new features by setting the appropriate flag in
about:flags. Blink will carry over support for all currently existing
-webkit- prefixes, but will be removing the prefixed features in favor of the unprefixed rules as soon as it is safe to do so.
The other good news is that there are once again four major rendering engines on the web.
As much as web developers might like to see the web have a single rendering engine that all browsers use, that sort of monoculture doesn’t lead to a healthy web. It’s interesting to note that Google’s fork appears to be motivated by this very problem, albeit from a browser maker’s angle — the sheer number of projects using WebKit meant development wasn’t moving fast enough for Google.
Adam Barth, Software Engineer at Google, writes on the Chromium blog that Google’s decision to fork WebKit was “not an easy decision.” But Google believes that “having multiple rendering engines — similar to having multiple browsers — will spur innovation and over time improve the health of the entire open web ecosystem.”
Google has outlined a new policy regarding experimental new features that differs significantly from WebKit’s here’s-a-new-feature-just-ship-it policy. Blink will instead limit new features to those that have at least been proposed as standards and preferably already have at least one other implementation. In those cases where WebKit is the source of a new feature, Google has pledged to “propose an editor’s draft (or equivalent) to the relevant standards group” and “discuss the feature publicly with implementers of other browser engines.”
For web developers little will likely change in the sort term. The first browsers with Blink at their core will not be on the web for some months and when they do arrive they will at first differ little from WebKit. The longer term picture will likely look pretty much like the web before Opera killed off its Presto rendering engine last month — four major browsers with minor differences between them that require testing to ensure total support.
There’s also the question of what happens to the WebKit project. Google has been one of the driving forces behind WebKit for some time. Now those contributions are gone and it’s up to other WebKit supporters — Apple, BlackBerry and Samsung, among others — to pick up the slack (with Samsung joining in Mozilla’s next-gen rendering engine project it’s unclear exactly how much commitment Samsung has to WebKit).
For more background on the Blink announcement, see Google’s FAQ. For one of the best all-around, unbiased looks at what Blink means for the web, see Peter-Paul Koch’s write-up over on the QuirksMode blog.