jQuery Mobile 1.1

At last! jQuery Mobile has released the much anticipated 'Fixed headers and Footers' fix we've been waiting for.

As discussed previously, there was no good option for Android. The third party js widgets were slow to respond, jittery and buggy.

But now we can have fixed CSS headers & footers using native page scrolling.

I'm going to test it out and report my findings. Stay tuned...

jQuery Mobile RC1.1

At last! jQuery Mobile has released a candidate for the much anticipated version 1.1 with the 'Fixed headers and Footers' fix we've been waiting for.

As discussed previously, there was no good option for Android. The third party js widgets were slow to respond, jittery and buggy.

But now we can have fixed CSS headers & footers using native page scrolling. (If you want to know why it was such an issue, see this blog and vlog by Brad Frost.)

I'm going to test it out and report my findings. Stay tuned...

Sencha report on Mobile Chrome

Sencha Labs does a good job of putting HTML5 browsers through their paces.

As I was, they're quite well impressed with Mobile Chrome, but have already found some things lacking. This quote just about sums up my feelings on the subject of compliance versus real-world performance:

"As we’ve said many times previously, many mobile browsers do well on the checkbox tests like Modernizr, but fall short when it comes to real world applications and content. (In some cases, mobile browsers have even reported support when none exists.) So for real world testing, we use a collection of our own favorite HTML5 sites and demos.

First up, the new CSS properties for mobile content. On our HTML5 wish list for 2011 we asked for high performance position: fixed. And Chrome for Android delivers. For simple pages, Chrome for Android does a top notch job of glueing fixed position content to the screen. Fixed headers and footers for simple mobile optimized pages are now easily implemented without having to use a framework. However, the browser struggled when trying to maintain fixed positioning on more complex pages, particularly when combined with pinch/zoom. We saw poor frame rates and occasionally content disappeared or was misplaced. Happily, the very new -webkit-overflow-scrolling: touch property, which debuted in iOS 5, is also now available in Chrome for Android. It’s smooth and fast. (Nice job Chrome team!)"

See the full report here:

HTML5 Scorecard: Chrome for Android Beta

1st Impressions: Google Chrome Beta on Android ICS

Turns out I was right: Google have been working on Mobile Chrome. (I assume it will eventually replace the deficient default Android browser.)
As a x-platform HTML5 webapp developer, I have been burned BADLY by the default Android Browser. It sucked in four main ways:

- internal scrolling widgets (like iScroll)

- form rendering

- non-GPU accelerated 2D transforms

- inconsistent implementation from different OEMs.

The ICS default browser was a slight improvement in forms, but still full of rendering glitches and obviously not utilizing GPU acceleration for ops like scrolling and map panning.
First impressions on Android Chrome: Logistically we should see almost no fragmentation through Chrome than we do through the mangled browser implementations we are getting from the OEMs. (However, it remains to be seen whether some phones (typically HTC) will still omit to implement multi-touch in the browser from ICS forward, but it's a real problem for advanced web apps today.) Form rendering is better, rendering glitches are reduced, but performance is still on par with the ICS default browser. What gives? Chrome claims to implement hardware accelerated rendering? Compare Google or Bing maps on the web with the native implementation and you'll notice obvious lag. Then browse to the same URL with iOS Safari and you'll see how it should be done.
C'Mon Google - We expect better than this. You're LAGGING behind. (Pun intended.)