There’s a perception that being in developer relations for a browser maker is all glamor and glitz involving lots of jet setting and rockstar-like experiences. So far I haven’t personally found that to be the case but in looking at the life of Opera evangelist Bruce Lawson, I think he may be fitting that description.
Helping fight the good fight for standards, Bruce is constantly on the move either updating his awesome book Introducing HTML5 (which is regarded as one of the best HTML5 books out) or attending developer conferences to read the pulse of the community.
With Opera’s recent shift to the Blink rendering engine, I managed to snag some of Bruce’s time to ask him how the shift will change the Opera browser.
I co-authored the first book on HTML5, "Introducing HTML5" (New Riders). I’m one of the founders of HTML5Doctor.com, and was a member of W3C's Mobile Web Best Practices Working Group. I evangelise open web standards for Opera, the oldest browser manufacturer whose mobile, desktop, TV and embedded browsers are used by 300 million people across the world.
Developers should find that Opera behaves as Chrome does.
Well, it would be nice if it went without saying that web developers should develop for the web and not individual browsers, and these days all browsers have great standards support. However, one of the problems that we had is that developers didn't test on Opera properly – because many devs are in the USA, and our desktop browser has a high market share in countries outside the US. So we've recently changed the rendering engine inside Opera Desktop and Opera Mobile to the Blink rendering engine that Google Chrome uses (we're the first to ship Blink-based browsers). Developers should find that Opera behaves as Chrome does. Because of greater compatibility with mass-market sites, and a more visually appealing UI, and some unique features, we're aiming to grow the user base more in the USA and Western Europe.
We have some unique features in both desktop and Android. One is off-road mode, which saves bandwidth and makes sites render faster. Another is Discover, which is visually appealing, curated content which can be customised to show certain languages and categories. Then, on Desktop, there's Stash – a place where you can save web pages for viewing later with a visual snapshot of the site and its text saved in the browser for later full-text searching.
We've long been known for innovating in browser UI (tabbed browsing, Speed Dial etc) and by using Chromium, we're able to get our developers making new, innovative interfaces rather than solely focussing on making our own rendering engine
When Opera Mobile and Desktop were based on Presto, there were four rendering engines on the market: Presto, WebKit, Gecko and Trident. Now there are four: WebKit, Gecko, Trident and Blink – and the same engineers who developed Presto are actively enhancing web standards support in Blink – enhancements that can be used by anyone.
Moving to Chromium gives Opera Mobile greater compatibility with sites that were coded with only Android and iPhone in mind, so serves our customers better – but working with the Chromium team helps break the incorrect perception that "only WebKit matters".
Our Opera Mini product has traditionally been the market leader on feature phones, as it does the heavy lifting on our servers, so it allows people with very low-powered phones to use the Web. It's used on over 3000 different devices world-wide – many of which we've never heard of – and is often the only way that people can join the Web in some emerging economies. But it's not just a featurephone product: compression and speeding up rendering is just as important on smartphones. We've seen the share of Opera Mini smartphone users in Asia Pacific countries increase from 9% to 32% (see opera.com/smw for monthly insight into worldwide mobile web use).
It's harder for developers to get paid when there isn't an installable product.
Also, browsers can help make HTML5 sites feel more app-like. Watch Opera for an interesting product that does just this.
I think the web stack is in pretty good shape these days. There’s work to be done making sure that sites can work offline (Appcache-done-right, in whatever guise it comes back) and with web payments. The lack of any useful way for developers to deal with responsive images is a problem, 18 months after it was flagged up.
My biggest worry isn’t the pace of standards development so much as lack of browser choice. Paradoxically, we have the most powerful and interoperable browsers that we’ve ever had, yet many platforms don’t allow the users to choose their browser.
Confusion is the word, indeed. I like the fact that the WHATWG keeps a living standard, that’s always up-to-date. But it means that lots of the stuff in there is really experimental, and not implemented anywhere (or even ready to be implemented, in some cases). It’s also really useful to have just one spec containing all the things.
However, it’s a shame that there are discrepancies between W3C and WHATWG specs. For example, the main element is really well specified in W3C spec, but badly specced in WHATWG. I’d advise developers looking to see what they can use now to look at the W3C version.
It’s a mash-up of memes from 2003, when I first (and last) redesigned my blog. It’s a combo of oolong the rabbit that balanced things on its head (http://en.wikipedia.org/wiki/Oolong_(rabbit)) and goatse, which isn’t a goat. Look it up. Or rather, don’t.
We’d like to give a big thank you to Bruce for taking part in this interview.