Mobile browser rendering

Article Retired

This article has been retired, and will not receive any more updates.

Since writing this article, very little has changed except Opera Mini. Opera Mini 4 for the test device has improved capabilities. It can either render the page as shown here, or very similarly to the Series 60 Browser (see my notes for that device for my opinion of that approach). It still respects handheld media, however, which sets it apart from the Series 60 Browser.


In this experiment, I put several mobile browsers through a series of pages. Sure, some of them are nasty pages, but they are real pages, that browsers should be able to deal with. In many cases, they all rendered pages fairly well, but the Web is not made up of just easy pages. These represent some of the common design types that are in use, and like most real Web pages, not all of them are designed to work with small screens. A good mobile browser will be able to cope with all of them. Let's see what happens.

Where possible, the test platform was Pocket PC 2003, one of the most efficient device operating systems, and a device with (in most cases) plenty of memory to spare (the tests were performed in 2005-2006). The browsers were:

Pocket Internet Explorer
The default browser on Windows CE (used on the Pocket PC).
One of the most popular mobile browsers.
Minimo (Mini Mozilla - using the same engine as Mozilla and Firefox)
In development.
Series 60 Browser
The new browser used by Nokia on the third edition of its Series 60 handsets. Important; see the note below.
Konqueror Embedded
Still in development - for now it seems to be a project designed only to get Konqueror packaged in such a way that it can run on a device.
A browser for mobile phones, installed by default on some of them - tested on an emulator set up with the same memory as the Pocket PC.
One of the most popular mobile browsers, and is the default browser on a large number of mobile devices.
Opera Mini
Fairly new, but rapidly becoming one of the most popular mobile browsers, due to the fact that it can run on devices with extremely low resources. It still uses Opera, but it is rendered on a server, formatted using Small Screen Rendering and the rendered page passed to the phone.

Minimo was by far the worst behaved of all the browsers. It required a whopping 11MB of storage space just to install (that is more than the combined size of all the other Pocket PC browsers), took forever to start, and used up all the remaining 30 MB memory to run, meaning that the screen capture program was unable to run. I had to get a new screen capture program that was much more annoying to use, and on top of that, Minimo ran out of memory and hung several times while loading pages (which it did monumentally slowly). It certainly was not "mini". To be brutally honest, if I did not know any better, I would have thought Minimo was a joke. It is simply too resource hungry to run on most devices.

Nokia's Series 60 Browser was not available when I originally wrote this article, so the screenshots were mock-ups made from Safari (the engine used by the Series 60 Browser), and were made in line with the screenshots and flash demonstrations provided by Nokia. It turns out they were surprisingly accurate, with virtually no differences between them and the real pages. Most of the mock-ups are so good that I see no need to replace them with a real screenshot, as they look virtually identical. I did not, and will not, test the older Nokia browser. It does not support tables, makes a mess of even the most basic CSS, and cripples script, so its approach is not to reformat pages, it just forgets to format them in the first place. It is not even in the same class as these other browsers. If you want to see how it looks, disable tables, scripts, and css, then tell your browser to ignore all structural and presentational elements and attributes. Then make your window really small.

Konqueror embedded was available for download, but it refused to compile on either my SuSE or Debian installs, or a friend's Gentoo install. It would not compile on my device emulators either. The pre-packaged binaries were reported as invalid archives, so they also would not run. I did extensive searching, and found many screenshots which showed the overall behaviour, so I made a mock-up that replicated this behaviour, using Konqueror on a desktop.

Note, I did try to test ThunderHawk, but after demanding my life story, it then refused to load any pages at all. For now, its rendering behaviour is supposed to be very similar to the Series 60 Browser (relying on a virtual screen size - see my comments about the Series 60 browser for more details), but it uses server side processing, to compress and format the page. What I can say is that it insists on running in landscape mode, and uses its own virtual keyboard instead of the system one.

Screenshot hosting thanks to Orca.

Note: In most browsers, the screenshots will automatically scale to fit the available screen space. You can click the screenshots to see them full size.

One of the biggest news sites. It is a fairly typical example of a rigid nested table design. Inflexible, cluttered, and certainly not designed to work with hendheld devices. A lot of the styling relies on background images, but is not totally dependent on them. The screenshots concentrate on one specific part of the page, where the use of background images is most apparent.

This is a fairly simplistic CSS standards based based page. It has a logo image, and turtle image at the top, including a striped background. The main content is positioned on the left side, with some links on the right. It does not have a handheld stylesheet, but due to the fluid design and lack of complexity, it should be relatively easy for the browser to reformat into something useful for a small screen.

A site I made a while ago when I was still learning how to make Web pages. It uses a simple frameset - and unlike many pages, it actually uses a frameset the way it was supposed to be used. It has a noframes fallback if the browser needs it. The left panel contains all the navigation, and the right panel contains the changing page content. The main page relies heavily on tables, but for the right reason; displaying tabular data, since the site is basically an interface to a database. The left panel also relies on tables, but for the wrong reason; to make the tree structure look right. The page uses CSS media queries to make sure the tables remain functional on a small screen.

One of the most popular Web sites. The bandwidth this site uses is phenomenal, and just by having them link to your site, it can easily be enough to wipe your site out for a week. Take it from my experience ;) Anyway, the site recently underwent a change to make it rely on CSS instead of tables. The page is fairly large, but it is reasonably well structured. Unlike most of the other examples, this page has a handheld stylesheet. It is designed by the author to display the page perfectly on a device with a small screen.

Note, I also have a handheld stylesheet on this page. Pocket IE ignores all stylesheets, Minimo ignores the handheld stylesheet, and NetFront randomly picks a few styles from all of the stylesheets and applies them together. By freak chance it actually looks OK, but it would be much better if it just applied the correct stylesheet. If you have Opera, you can try the handheld stylesheet by pressing Shift+F11 (this will enable Opera's handheld preview mode), then change the size of the window to see how it copes at various resolutions.

This site may belong to an Opera user, but don't let that make you think it is biased in any way. This site renders beautifully in all desktop browsers, relying on display:table; for standards compliant browsers, and floats for Internet Explorer. All browsers are given a good chance to render this page, so lets see how the mobile browsers cope.

One of the biggest Web development reference sites. Its design is based on a frameset. There is a top frame for the logo and a breadcrumb script, a left frame for the navigation, and a main right frame for the content. The page does not use the normal frameset approach. Instead of a noframes section, it has a complete page, and uses a script to generate the frameset only if the browser is capable of running the scripts used by the navigation page. Without frames, the browser is given an alternative view of the navigation, leaving the site fully accessible. As an additional bonus, the scripting design allows the frameset to be bookmarked, so that it will return to the correct pages within the frameset. old design

You may be familiar with this page. It is a simplistic design based on borders and colours. Margins are used to make the page appear centred, while still remaining fluid. The page uses CSS for the design, and does not rely on tables. This design is very simple, and should be easy for browsers to cope with, and reformat as needed. new design

There is also the new design for the site, fairly typical CSS based, with a navigation panel on one side. It uses handheld media and media queries to help the page display on a complete range of screen sizes, and of course; handhelds.


This is Microsoft's own site, documenting the capabilities (or lack of capabilities) of Internet Explorer. It is based on framesets, that it enforces very heavily. It is not possible to view the site without framesets. The layout uses 6 rendered frames (in 4 separate framesets); one at the top for the logo and menus, one on the left for the search field, one under it for the "sync toc" function, one under that for the tree structure, then a small frame on the right for the words "Welcome to the MSDN Library", and finally, a main frame under it for the content.

Note that this page serves garbage to Opera (and possibly other browsers) if it identifies as itself, so Opera has a user-agent override set on this site to make the site think it is something else.


Well, it does not take too much effort to realise that only two browsers successfully coped with all the pages, and they share a common name. I am quite sure there will be some that defeat Opera, probably ones that really rely on desktop screen size to work (such that they will not let you continue unless your screen is a certain size), or pages that deliberately sniff and block it, or maybe ones that rely too heavily on use of plugins. But in general, Opera seems to cope with difficult pages far better than the other device browsers.

Add in it's impressive capabilities, such as its ability to use XMLHttpRequest (AJAX) applications, and its very good support for standards such as DOM, CSS (even particularly useful things for devices, like media queries, and the obviously important handheld media), and SVG. Its low resource usage, and small footprint are also very important benefits. All in all, Opera manages to outshine the other device browsers.

See disclaimer

Back to Opera resources | Back to How To Create