Friday, March 13th, 2009
PPK on Mobile Browser Compatibility
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.
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.
@Rey
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… ;)
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.
@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”.
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.
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”
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.
I agree with “mobile web development” definition. Supported events are different, resolution features are different (with or without zoom), common mouse/keyboard events are different.
Who developed a portal for iPhone and/or Android (x.facebook for example) knows perfectly how different is the “mobile world”. It is not just about the resolution, it is about clickable areas (forget the mouse pointer), restricted CPU and RAM (different common libraries won’t work them), limited pixels for bigger fonts (supported?) … JPEG are not well rendered as PNG, the scroll block script executions .. etc etc … a research focused on most common mobile browsers can only bring benefits for all of us. Just try to imagine that without this research I had to spend hours to create a truly simple interface as this is, specific for iPhone and Android (WebKit), obviously a non-sense for desktop PCs.
I do not understand why we are still supporting IE6 but we do not accept the fact that mobile browsers have other kind of limitations … so IE6 comparative table is welcome but this kind of research is not?
Two different worlds, imo, well done PPK and who sponsored the research!
@WebReflection
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) … ;)
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 ;-)
@WebReflection
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… :)
@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.
@Joeri: “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”
I could agree with you if we don’t have Opera Mini, but we have. Opera Mini 4.x saves the mobile web in low end devices because it is basically a proxy of the engine of Opera 9.x in Opera servers. Opera Mini 4.x can be installed in virtually ANY phone or mobile device and renders correctly almost any web site. And Opera Mini supports AJAX…
I agree with ThomasHansen the mobile web world is underused current mobile devices have more power than expected including not very popular browsers like NetFront 3.4 included in many phones (3.3 is very poor). Of course you cannot expect the same rich behavior got in desktop and forget using tons of JavaScript code. But for conventional web applications they work fine including AJAX.
For instance try to open this web site with a decent mobile browser (or use Opera Mini 4 in your phone or in desktop using microemulator or emulators of mobile browsers).
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.
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…
@TNO
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…!
@ThomasHansen:
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.
@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.
@WebReflection
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 :)
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.