Opera Spills the Beans
As means of early summary, Opera have written the following:
- This will require no changes to your web development practices: keep coding to standards!
- Opera Extensions that you’ve built aren’t obsolete
- Opera will contribute to the WebKit and Chromium projects
- Our work on web standards to advance the web continues
These points indicate that this is largely an under-the-hood change, with little impact on routine coding. Functionally the browser will remain the same, extensions will continue as they have before. Opera are remaining in the browser game, and will have a hand in advancing the web as well as the WebKit and Chromium projects.
Opera’s rationale for the change is that while they built Presto at a time when the competition was sorely needed versus Internet Explorer and Netscape, it now makes less sense to duplicate efforts made on other modern engines (ie WebKit). It’s a reasonable rationale, but to me Opera having their own engine made them stand out as they could implement web standards at their own pace. This has been borne out in the past as they have often been ahead in certain areas. I even remember when Opera was the first browser to have native tabbed browsing, and Firefox at the time required a plugin!
A (quite) probable cause is the trend developers have been following in building styles specifically for WebKit browsers, making heavy use of the
-webkit- prefix. This was brought to the fore last year by the kerfuffle around Opera announcing support for certain WebKit-prefixed CSS properties. Today’s news almost seems like a logical next step.
Up until now, the major rendering engine and browser landscape has been:
- Gecko – Firefox
- Presto – Opera
- Trident – Internet Explorer
- Webkit – Safari, Chrome
Given this change, the landscape becomes:
- Gecko – Firefox
- Trident – Internet Explorer
- Webkit – Safari, Chrome, Opera
From what I can tell, this revelation has both positive and potentially negative ramifications.
It’s also been suggested that by switching to the “popular” engine, Opera may lose credibility in web standards development. I don’t see how – they are still Opera.
Peter-Paul Koch made the following remarks:
As many people remarked, we’re trading in a bit of diversity for an easier job as web developers. Opera-WebKit will likely be more similar to the other WebKit-based browsers, thus leading to less premature hair loss among developers. So far so good.
Still, there’s a dark lining to this silver cloud. [...]
The problem I’m having is “many of which have only been tested in WebKit browsers.” Note carefully what this means: we web developers haven’t been doing our jobs properly. We didn’t bother to test our mobile sites on Opera Mini, even though it’s roughly as large as Safari iOS and Android.
I see this as a personal fail. I evidently haven’t been outspoken enough on the topic. I should have yelled in everybody’s ear until they did the proper thing.
It’s our own fault.
Emphasis mine. The quote is revealing in how web developers have essentially forced this situation.
Jake Archibald, a Google employee, reflects on the announcement and what it may mean for the web. Nice to see the pros and cons presented by someone who works for a competing company. John Resig even likens WebKit to jQuery with regard to its widespread use.
Opera can contribute their knowledge and skills to the WebKit project, making it all the better. Hopefully things learned from maintaining Presto – such as Opera’s advances in HTML5 form element support – will make a positive impact.
Christian Heilmann touches on this – he remarks:
[...] I always called Opera the Douglas Crockford of browsers as it was ruthless in its implementation of standards. If something didn’t work in Opera there is a good chance that you did something wrong. Even better – fixing it in Opera in most cases meant looking at how the W3C standard meant things to work and write your code accordingly, which in most cases meant no change in other browsers, but cleaner code overall. Opera was my linting tool.
This reflects the care Opera have taken in their implementation efforts. I suspect this would continue, regardless of the engine they use.
Recognizing that there is a difference between the browser and the rendering engine, this move means there will be one less engine to test for. Besides Internet Explorer, browsers tend to be updated on a regular basis, so I don’t imagine Presto-based installs will remain in wide use for long. Peter-Paul Koch estimates the first WebKit-powered Opera will appear this year, and that it will take a few years for Presto use to drop off entirely.
Generally, in my admittedly limited experience, Opera hasn’t been troublesome in standards support, so not much accommodation has been needed. Switching to WebKit will further level out browser differences. Nonetheless, while the
-o- prefix in stylesheets will eventually become redundant, they should be kept around for the immediate future for backward compatibility. There aren’t very many. Ultimately this will slightly reduce some development work.
While Opera putting their weight behind WebKit can be a good thing, the resultant withdrawal of Presto will reduce diversity in the rendering engine landscape. It’s not to say that Opera (the browser) will become “yet another WebKit browser”, but that it may be less able to distinguish itself from the competition. In the past, Opera (the company) have been ahead in implementing various parts of web standards, notably HTML5 form elements. With the switch to WebKit, Opera’s pace may be tied to that of the WebKit project, for better or for worse. The flip side (also mentioned above) could be that web development and testing may be eased by greater consistency between browsers.
This leads to a concern that the web browser landscape may be moving toward a WebKit monoculture. Sure, there’s still Internet Explorer and Firefox with their distinct engines, but WebKit is a big player on mobile devices, and growing on desktop/laptop systems. This can be good or bad; it’s to early too tell, but it worries me slightly. Competition is a good thing, and removing a player (Presto, in this case) can adversely affect the landscape, and possibly make the other players (the other engines) complacent. Which is kind of veering towards where the browser market was in the early days of Internet Explorer 6.
Returning to the prefixes issue, given the Opera will be using WebKit I have to wonder how browser-specific CSS can be issued. There will be multiple browsers supporting WebKit, yet each browser may use a different version, and likely support different features (as Safari and Chrome have done, I believe). Could styles still be written to target specific browsers, or does using WebKit simply lump them all together?
Time will be the Judge
It’s much too early to know how this will turn out. Here and now, I’m very mixed. In past years Opera has been a unique browser, with it’s own engine and features, with better standards support in some regards. By switching from Presto to WebKit, there is some perception in the community that Opera will become “yet another WebKit browser”. I don’t necessarily agree with that sentiment. I’ve no doubt the Opera team considered this long and hard prior to the announcement, so they may well believe this is the best step forward.
I’ve been reading a number of other developers sharing their thoughts on this change. Below I’ve linked to a number of very interesting views.
- I will miss the “Douglas Crockford of browsers” (Christian Heilmann)
- Opera switching to WebKit: thoughts and guesses (Peter-Paul Koch)
- WebKit is the jQuery of Browser Engines (John Resig)
- Presto Change-o (Eric Meyer)
- The WebKit Culture & Web Rendering Engine Diversity (Robert Nyman)
- Devs respond to Opera WebKit switch (.net Magazine)
- Opera and WebKit: a personal perspective (Bruce Lawson)