Friday, March 13th, 2009

PPK on Mobile Browser Compatibility

Category: Mobile

Peter-Paul Koch (AKA ppk) has truly provided a tremendous service to the development community over the years building one of the most important resources in determining compatibility of web standards among the major browsers, the Compatibility Master Table. This resource is referenced often by developers and publications and is exhaustively granular in its data.

With his focus shifting to the mobile space, PPK continues to serve the community by providing similar data for mobile browsers.

Right now I’m doing basic tests while also figuring out what “basic tests” means in the mobile space. It turns out that I even have to test basic CSS stuff like font-style. Many of my already-existing tests use such typographic CSS to denote whether a browser supports a certain selector or effect; but if a mobile phone doesn’t support the CSS in the first place, my tests will misfire horribly.

His Mobile Compatibility Tables, while still very new and a work in progress, will surely be of tremendous help to the many developers who are now looking to mobile web development as the next big wave.

He’s already collected a large amount of information on the following mobile browsers:

  • Opera Mobile
  • Opera Mini
  • WebKit
  • NetFront
  • Blackberry

and for the following browser capabilities:

  • Events including key & click
  • Basic DOM & Ajax support
  • Basic font CSS
  • CSS Media
  • Focus, blur, scroll
  • Screen orientation support
  • Font sizes

If you’re a mobile web application developer, I urge you to go visit this great resource and even offer PPK feedback to expand his data.

Posted by Rey Bango at 5:03 pm

4.1 rating from 27 votes


Comments feed TrackBack URI

As usual, PPK is very thorough. It’s good that somebody thought of doing such a research, given the variety of mobile phone platforms and OS’es.
Sadly, there are a lot of red squares in the charts (and that is without including IE), which clearly shows that there are a lot of things that still remain to be done.

Comment by moisadoru — March 13, 2009

Great writeup, though I don’t understand this new focus on “mobil website development”. Shouldn’t “mobile web development” be the same as “desktop web development” apart from screen resolution and such…?
I mean, unless we’re talking about some obscure browser or WAP or something stupid like that, it’s [supposed to be] still HTML, CSS, ECMA and such. Which are standards, and if some cell phone browser doesn’t support things in these standards, then we should a) encourage him to support it, b) implement it ourselves (if FOSS) or c) vote with our feet…
To divide the web into “desktop web development” and “mobile web development” just creates arguments for new generations of lock-ins from vendors, or…?
I think what I mean is to stop calling it “mobile web development” and instead call it “web development for browsers with small resolution” or something… ;)

Comment by ThomasHansen — March 14, 2009

Well the browsers on modile phones seem to be reduced in functionallity somehow. So YOU as dev never know what is cut out and whats left in.

The mobile internet has started with the iphone I belive, before that (at least in europe) was wap. So the furture will be for sure internet on tiny resulutions. But until 2011 or so, everything will lack everywhere a w3c standard. So nice work from ppk.

Comment by Aimos — March 14, 2009

@Thomas: Thx and great feedback. Not having done web development for mobile browsers, it’s hard for me to tell you how substantial the differences are but I’ve heard from developers who have built web applications that cater to mobile that it’s not apples to apples.
I totally agree with you in hoping that mobile web browsers will be as standards compliant as their big brothers and that in the near future we can just say “web development” instead of “mobile” or “desktop”.

Comment by Rey Bango — March 14, 2009

I fully disagree on the classification based on devices, because there are myriads of devices out there, a small subset doesn’t help very much.

A classification based on browser versions is more helpful. For instance:

Opera Mobile 8.6x and 9.5 are very different.
The same for NetFront 3.3 and 3.4
The same for IE Mobile of WM 6 and 6.1 and the upcoming IE Mobile of WM 6.1.4 (IE 6 on 6)
Opera Mini 4.0 to 4.4 are basically the same (the real thing is in the server).
S40WebKit browser is more advanced than S60WebKit
There is an abyss between the browser in BlackBerry JDE =4.6 devices
And so on.

If you try to classify the mobile web from an AJAX point of view, forget Opera Mini <4, NetFront < 3.4, IE Mobile <WM 6, BlackBerry JDE <4.6 etc

For a complete list of the mobile browsers with AJAX support see the list of supported browsers by ItsNat, the Java based AJAX web framework I’m working on.

Comment by jmarranz — March 15, 2009

Sorry “There is an abyss between the browser in BlackBerry JDE =4.6 devices” what to mean:

“There is an abyss between the browser in BlackBerry JDE 4.5 or lower and 4.6 and upper devices”

Comment by jmarranz — March 15, 2009

Most of the smaller mobile browsers are based on XHTML Basic and Wireless CSS, no scripting (aka WAP 2.0). The smartphones try to adhere more to the HTML4 + CSS2 + JS side of things. Currently either you cater to the lowest common denominator and forgo scripting and complicated layout entirely, or you choose a subset of (high-end) phones to support, and figure out the compatibility matrix from there. The capabilities of these higher-end browsers are not well-mapped (the low-end is covered by WURFL). It’s nice to see people making work of it, though I still feel that the mobile web isn’t ready for scripting unless you target specific phones.

Comment by Joeri — March 16, 2009

I am now developing an Ajax portal for a customer of us and I am consciously developing it from the beginning with “mobile browsers” in mind. This means that I explicitly avoid stuff like drag and drop, righ clicking and so on. And hover stuff is only used as “candy” ant not “crucial” to run the application. I am even using left clicking to toggle menus and such, and it’s really not that difficult to develop something which will work “out of the box” also on the “mobile web”.
But yes, you have to be “sober” and avoid the temptations of “going berserk” and do all the stuff you “can” do…
But that’s really no different then developing for the “desktop web” anyway since temptations to go bananas will anyway bring you into trouble in the “desktop web” set alone…
So I must say that all though you are technically correct, I insanely disagree with you (or something) … ;)

Comment by ThomasHansen — March 16, 2009

Thomas, d&d could be possible in a different way. Both iPhone and Android supports d&d for system icons, I could expect something similar in a web page (pictures organization).
What I mean is that these two worlds are part of the same “subject” but still completely different for concepts, possibilities, events, features (present or missed, in any case different). The fact these are A grade browsers does not mean they are in the same level of desktop.
Silly example, Nintendo DS features analysis is something completely different from XBOX360, PS3, etc … but Nintendo DS is still a console, isn’t it? Well in this case, we have to consider a different approach for everything, so what is possible and what is not (banally speaking video streaming, as example) is absolutely important and a “must know” for developers (how can you decide to do a porting of a game into the DS just thinking: come on, it is a console!)
I hope you got my point ;-)

Comment by WebReflection — March 16, 2009

I do get your point … ;)
Though I am a (self proclaimed) standard “fundamentalist”, and I guess my point is that there are standards to follow and use, and as long as we implement the standards we should be pretty safe. At least when coupled with demanding that the browser vendors follows them and don’t do any EEE (Embrace, Extend, Extinguish)
If you go 150 years back in time I am pretty sure that people would have similar debates regarding different vendors implementation of railroad tracks. Today (unless you’re in Tokyo on a Mono Rail that is) debating whether or not supporting “RailRoad I LLC’s” tracksizes or “RailRoad II LLC’s” tracksizes are of course a relic of the past. And so will “mobile web” versus “desktop web” pretty soon be. And the less we focus (and fall) for lock-ins in different browser vendors techniques, the faster we can get to that point – the point where we have standards implemented as an *absolute* in all browsers…
Sometime System Development is the; “art of knowing what NOT to do” and not the; “art of knowing all different possibilities” or something… :)

Comment by ThomasHansen — March 16, 2009

@ThomasHansen: different countries use different track widths and currents. The trans-european TGV crosses some borders on inertia alone because the voltages change at the border.

By which I mean to say that there will probably never be a point where standards are an absolute in browsers. Standards move too slow to ever catch up to the bleeding edge in capability.

Comment by Joeri — March 16, 2009

It’s hard to justify writing mobile browser specific objects and styles where I work, which is in writing financial services web apps. There are too many mobile browsers out there and they change too fast to make it worth it. From what I’ve seen, as long I serve basic HTML 4, and enhance it progressively with CSS/JS that same way you would for any set of desktop browsers, my apps work fine 99% of the time on any mobile browsers that can handle HTTPS.

Comment by WillPeavy — March 16, 2009

I’d be primarily interested in the level of XSL support in these browsers. At least I would then be able to abstract most of it away…

Comment by TNO — March 16, 2009

I’ve seen your ideas with XSLT in the browser, but why don’t you run this on the *server*…?
Then whatever XSLT the browser supports becomes irrelevant…!

Comment by ThomasHansen — March 16, 2009

In regards to old school mobile devices I would agree with you that you would have to for anything non trivial. When it comes to newer devices with Fennec or Webkit or newer Opera though I believe we should take advantage of their platform capabilities and reduce server and traffic load.

Comment by TNO — March 16, 2009

@ThomasHansen … “standards implemented as an *absolute* in all browsers” … even physic events we know are not absolute but different in “other planets”, that’s what I mean when I say that mobile development is a different world (environment if you prefer). Anyway, you know that standards and reality as truly different and standards are, as other said, slow to mature and become concrete. Nowadays, a lot we have in latest browsers is from working draft slightly updated in months, if we are lucky … do you really want to wait those specs? And what if those specs fails as they did before? The reason now they are different and a bit more open minded?

@jmarranz … I work with ExtJS on daily basis, and it is the perfect example to demonstrate how different is the mobile world from the desktop one. That page is completely stressful with my Android! Moreover, I cannot click the little [x] to close widgets and I have to scroll the page everywhere to find or work over the grid, tabs, whatever. Mobile Web is different, you cannot present that kind of page saying: you see? it works there too … cause usability is under zero and the fact you have to download a heavy library as Ext JS is is a non-sense, since it does not make the user experience better but just a nightmare to navigate with a small resultion touch screen. iPhone? I am sure after that page could do few other things, since 2Mb are easy to reach when we use a perfect for Desktop PCs Framework, as ExtJS is.

Comment by WebReflection — March 16, 2009

Yes I agree, this page is not tuned for mobile devices.

Anyway you are wrong in some things:

This example uses ExtJS CSS and HTML generated layout but no ExtJS JavaScript code, because it takes the CSS and HTML layout generated by another true ExtJS application (read the “Introduction” in the example) and is reused as pure HTML templates in ItsNat, that is server centric (in summary is not an ExtJS application). This is the reason it works in almost any mobile browser because ItsNat is server centric and the JavaScript loaded is minimal, that is very good for mobile web because more power to the server is more power to the device. The client centric approach (using big JavaScript libraries) will work in some years but not today.

The good news is a web application not designed for mobile with tons of HTML (HTML layout of ExtJS is bloated really bloated because is for desktop) and CSS, based in AJAX using the single page interface technique works in almost any decent mobile browser! and in all mobile devices using Opera Mini.

Of course an application tuned for mobile has a smaller display area and must be not so visually bloated :)

Comment by jmarranz — March 16, 2009

More good news:

I’ve just discovered Bolt Browser.

This JavaME (MIDP2) mobile browser is VERY interesting because is very similar to Opera Mini, like OM is proxy based with a WebKit in server and may run in virtually any mobile phone. It is more practical than Opera Mini in single page interface/AJAX based applications because there is no need of scrolling when clicking something as in Opera Mini (this makes OM tedious in webs with large page areas).

Is just supported by ItsNat in my internal version, and updated my example to support this browser, open it with Bolt.

Comment by jmarranz — March 19, 2009

Leave a comment

You must be logged in to post a comment.