Google Forks Webkit

Ben Moss By Ben Moss  |  Apr. 04, 2013

Yesterday, anyone old enough to have been working during the browser wars, felt the icy cold fingers of fear creep up their spine when Google announced that its browser Chrome will be abandoning Webkit in favor of their own Blink rendering engine.

Based on the open source Chromium Project, that will be forking Webkit, Chrome is the biggest browser in the world: statistics place Chrome usage at anywhere up to 41.9%, and growing at more than a percent each month; it’s trusted across MacOS and Windows; it is also the dominant browser in Central and South America, Europe, India and Northern Asia.

Chrome is also making significant progress on mobile, with the Android operating system increasing in popularity and Apple’s iOS — which is the only area the other major Webkit browser, Safari, dominates — slowly losing market share.

Until now, Chrome has relied on the Webkit rendering engine, a framework devised in the early 2000s which critics such as Google say was designed for a different web landscape. Although Google claims that initially focus will be solely on cleaning up the existing codebase and deleting unnecessary files, the new Blink rendering engine is, designed for the modern web with a host of performance improvements, notably in the area of DOM rendering — which is vital if the rich media aspects of HTML 6, 7 or 8 are ever to become a reality.

All of this sounds very positive, until you look at the practicalities for web designers. Presently we test across six major browsers: Chrome, Safari, Firefox on MacOS and Chrome, IE, Firefox on Windows. Some dedicated testers will also check for Opera compatibility. The task is made simpler by the fact that 9 times out of 10 Chrome and Safari render identically thanks to their shared rendering engine. The introduction of Blink means that Chrome and Safari will probably not be rendering in the same way in future.

The issue is even larger for the mobile web. Device emulators now need to find a way of rendering not just Webkit and Mozilla, but Blink too. That work begins now, but it’s likely that for a period of some months, designers will have to have access to multiple devices to ensure Chrome compatibility.

“we believe 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” — Adam Barth, Software Engineer Chromium Project

Perhaps the biggest issue is one that initially looks the most positive: Chrome will no longer be supporting browser prefixes. In other words, whilst you might currently write in CSS:

div {
  -moz-column-count:4; // Mozilla
  -webkit-column-count:4; // Webkit
  column-count:4; // default

There will be no additional:

-blink-column-count:4; // Blink doesn't support this

Browser prefixes bring a host of problems, quite apart from being ugly and inconsistently supported, they also create file bloat and encourage diverse implementation. So can we stop using browser prefixes? No, they’ll still be required for other browsers just as much as they are now.

Instead of using a browser prefix, anything Chrome considers experimental will be held behind an ‘enable experimental’ flag. Which means you can enable everything experimental, or nothing at all.

Furthermore, by removing the browser prefix Chrome sets itself up as the ‘default’ behavior for the web. If Chrome’s implementation of a feature doesn’t sit right, the option to tweak your code with a browser specific prefix isn’t there. The chances are, we’re going to have to go back to using JavaScript to ‘browser sniff’ Chrome and adjust the default CSS when required.

The forking of Webkit and the creation of Blink will be highly beneficial to Google; Chrome will be a faster, even less buggy, and faster to evolve. The benefits to users will be a light, fast browser built for the modern web. The consequences for web designers are likely to be a lot more headaches and substantially more hours spent tweaking CSS.


What do you think of Google’s decision to create their new Blink rendering engine? Do you think Blink will save you time, or create more work? Let us know in the comments.

Featured image/thumbnail, fork image via Shutterstock.