Opera software announced this morning that it is dumping its homegrown Presto rendering engine in favor of the increasingly ubiquitous WebKit rendering engine.
For all new products Opera will use WebKit as its rendering engine and V8 as its JavaScript engine, mirroring what you'll find in Google's Chrome browser. Apple's Safari also uses WebKit, though it has its own JavaScript engine.
Writing on the Opera Developer Blog, Opera's Bruce Lawson says the first WebKit-based Opera browser "will be for smartphones, which we'll demonstrate at Mobile World Congress in Barcelona at the end of the month."
While Opera's desktop market share hovers around 2 to 4 percent, the company's two mobile browsers have, until very recently, been the most used mobile browsers on the web.
Indeed, while Opera's official announcement is vague about the reasons for the switch, it doesn't take a soothsayer to know that the reason is mobile. One influencing factor is no doubt the fact that Apple's iOS only allows third-party web browsers if they use the built-in WebKit rendering engine.
Then there's the -webkit CSS vendor prefix problem. At least some of the blame for Presto's demise falls on web developers for developing against WebKit, rather than using web standards.
CSS vendor prefixes were designed to help web developers by giving them a way to target CSS to specific browsers and use proposed standards before they were finalized. The idea was to move the web forward without rushing the CSS standards process. Unfortunately, it hasn't always worked out that way. In fact, web developers fell in love with the -webkit prefix and often forget that there are other prefixes as well: -o for Opera, -moz for Firefox and -ms for Internet Explorer.
Using only -webkit means sites break in Opera even though Opera could have rendered the site just fine if the developer had bothered to include the -o prefix.
Of course, as Mozilla's Christian Heilmann points out, "content not showing up or showing up broken in your product is terrible for a commercial company – the web is never wrong, if your browser shows it wrongly it is your fault, right?"
It would always be Opera's fault in the eyes of most users and that's why the company decided to support the -webkit prefix last year. In many ways today's announcement is just one step further – if you're going to support the prefix, why not just use the rendering engine? That seems to be exactly what Opera has decided to do.
So what becomes of the Opera features you know and love? The DragonFly developer tools are most likely done for, WebKit already has its own developer tools. It's less clear what might happen to Opera's other unique features like the built-in e-mail client or Opera Turbo, which compresses webpages to give broadband-like speeds on almost any internet connection.
An Opera spokesperson declined to comment on the future of any Opera features, telling Webmonkey only that "compression is in Opera's DNA, but other than that we don't talk about features of unreleased products."
While I'm optimistic about Opera's WebKit future, it's hard to see the loss of a rendering engine as anything but bad news for the web. One less rendering engine means one less way to discover and fix bugs in web standards, one less place to see what you've done wrong. And Opera, while sometimes difficult to test in, was almost always right when it came to implementing web standards. In 13 years of building websites I've found no other testing environment in which I knew that if something didn't work, it was almost certainly my code that was wrong. And I'm not alone; apparently even some Chromium developers feel the same way.
But that won't stop developers who'd like to see a monoculture of WebKit from shortsightedly cheering this news.
Mozilla developer Robert O’Callahan summarizes why a WebKit-centric web is not a good thing:
WebKit makes a fine rendering engine and it does a good job of keeping up with web standards, but don't assume that just because a web browser uses WebKit under the hood that it will render your pages the same as every other WebKit browser. Just look at the rendering and feature differences between Chrome, Safari, Mobile Safari and Mobile Chrome to get a sense of the pain that awaits developers yearning for a WebKit monoculture.
The other possible downside to a WebKit Opera is that the company's once mighty voice for standards may not be heard as clearly amid the Google- and Apple-dominated WebKit developer culture.
Hopefully the WebKit community will find a place for the developers who brought us tabbed browsing, mouse gestures, "Speed Dial", Turbo, and an uncompromising support for web standards that made Opera one of the first browsers to pass both the ACID 2 and ACID 3 page-rendering tests. For its part Opera is starting off on the right foot, offering up code that brings Presto-quality support for the CSS Multi-column Layout Module to WebKit.
Hopefully Opera engineers will continue to bring the same kind of innovation to WebKit and Chromium as they did to Presto and with any luck WebKit will listen and the web will end up a better, if less diverse, place.
