Question

All,

I’m working on a web application for iOS that uses a fixed position header (much like Gmail’s mobile interface).

Since mobile browsers ignore position:fixed, this is a little tricky.

Then, I found Google’s excellent article on how they implemented it for the mobile version of Gmail:

http://code.google.com/mobile/articles/webapp_fixed_ui.html

The only problem – they left out several key pieces of code (as “exercises for the reader”). I don’t know if they did this to protect their own code, or just to keep the tutorial short.

In any case, I’ve been able to fill in most, but not all of the missing pieces. The part I’m stuck on… what to do if the momentum takes the scrollable area past the boundaries of the scrollable frame.

Here’s what the article suggests:

In our implementation we detect this case and handle it by queueing up several transitions. The first transition takes us to the boundary, here the final velocity is not zero so we need a different cubic-bezier timing function.
The second transition bounces past the boundary a little bit, the final velocity is zero so we can use the cubic-bezier timing function shown above.
The third transition decelerates the content back to the boundary using the build in ease-out timing function.

That makes sense, but a few things I can’t figure out…

1. How do you specify a webkit transition with a timing function in which the final velocity is NOT zero? In other words, when you use a cubic-bezier for the timing function, you can only specify the middle two control points – the fisrt (0,0) and last (1,1) are assumed. So, isn’t the final velocity ALWAYS zero?

2. How do you calculate what the velocity SHOULD be when you reach the boundary?

If anyone has worked out the details of this, and is willing to share it – that’d be much appreciated!

Answer 1

As shown on rumour sites, leaks of iOS5 have shown that workarounds will be no longer necessary. position:fixed just works.