Mobilism: Mobile Browser Panel

by Luke Wroblewski May 14, 2011

At the Mobile browser panel at Mobilism in Amsterdam, Netherlands representatives from Opera, Nokia, and RIM (Blackberry) talked about the mobile browsers they create, their implementation differences, and when we can expect device APIs in mobile Web browsers. Here’s my notes from the comments made on the panel.

  • Nokia currently has two Web browsers in development: Webkit for Symbian and OVI browser for Series 40 phones. When Windows Phone comes, whatever browser it uses will be on Nokia’s smartphone devices.
  • Blackberry 6 and onwards is using Webkit. Torch was first device with it. It most instances it is compatible with other mobile WebKit browsers.
  • Blackberry 5.0 browser had some elements of HTML5 supported, decent Javascript support but not amazing. Before 5.0, the browsers were not very good. Luckily, the marketshare of Blackberry 4.6/4.7 is dropping quickly. 5/6 is growing and recently surpassed 4.7 and below.
  • Opera ships the same rendering engine (Presto) in Opera and Opera Mobile. Opera Mobile browser is at version 11 and on Android and Series 60 phones. No longer supporting Windows Mobile 6.5 Full browser and rendering engine.
  • Opera mini is a proxy browser (thin client on the phone). The rendering engine (Presto) lives on the server. The request goes to the server and sends back a highly condensed file to render the page. Feature phones are not capable of running a full rendering engine on the device. Opera mini gets more use than 102 million monthly users on opera mini. 8.8 petabytes of data. 50 million people use Opera mobile monthly. In certain cases, people use Opera mini on smartphones to save on bandwidth, data costs, etc.
  • The OVI browser is also a distributed user agent. There is a proxy on the server-side. Works the same as Opera mini.

Browser Differences

  • Zooming on Blackberry is different on platforms. WebKit reflows text when you do a zoom. It will adjust line-breaks. People don’t want to scroll horizontally. This implementation is a bit different than other Webkit implementations. Larger screen devices do not re-flow text at all (Playbook).
  • Nokia has a large variety of devices. OVI browser and lower end devices wil reflow by default vs. zoom. The move is to touch only but for now there are still non-touch devices. For consistency, Nokia uses text reflow instead of zoom. All Symbian devices for sale now are touch-only - upcoming browser will be deployed to older devices too.
  • Mobile Safari and Android Webkit are not using upstream Webkit. They have forked to their own builds.
  • Blackberry 6.0 does not support HTML5 video but the Playbook does. It runs h.264 video. They hand this off to the system for playback.
  • Blackberry 6 supports position-fixed the way Android used to. In the Playbook browser there is actual support for position-fixed support. This is coming in Blackberry 7 for smartphones.
  • In Opera Mobile 11, the layout is calculated differently so there is a possibility for position-fixed in the future.
  • What to do with zoom and fixed-position element? Needs some evolution in the standard on how to zoom with fixed-positioning. Browser makers are doing zoom differently as they are trying to figure it out.
  • Opera recommends that developers do feature detection and make adjustments vs. using User Agent sniffing. General agreement from the panel to avoid UA String sniffing today, instead do feature detection.
  • Over 25% of apps being submitted to Playbook app store are Web apps. WebWorks is a widget platform that provides access to device APIs.
  • Opera only downloads media assets inside the media query that is needed. Other mobile browsers do not work like this.

Device APIs

  • Nokia had device APIs in WRT. Was ahead of the curve but never standardized things. WRT is 95% like a W3C widget, you need XML manifest and zip it. You can also wrap in a Qt app and use Qt WebKit and use HTML5.
  • Opera has been playing around with device APIs for years. Opera Mobile released a build with the device element that allows you to access the camera. They were about to release this but the specification changed that day. A week later, they shipped an updated version.
  • Specifications for device APIs keep changing. If you get too far ahead, you implement something proprietary. If you wait for standards, you might wait too long. It’s a balancing act.
  • “Once we ship something, we are very stuck with it forever" prevents freedom of experimentation.