Position: fixed revisited

Now that iOS, Android, and BlackBerry all have a new implementation of position: fixed let’s see what changed since the last time we looked.

Because it’s fairly hard to describe what mobile and tablet browsers do to position: fixed I decided to make four short videos, both to help you understand the issues better, and to practice a bit with shooting videos of mobile browsers.

I have the new OSs and browser versions available only on tablets, and not on mobile phones, so that’s what you’ll see in the videos. Nonetheless, the mobile phone use case is more important because the screen is smaller and the danger that the user can’t see part of the fixed layer larger.

All videos show this test page.


Opera Mobile 11.50
Android 3.2

Opera Mobile hasn’t changed its treatment of position: fixed: it still adheres to the “hopping” variant. The fixed layer is placed correctly, and scrolls with the page. When the user stops scrolling it jumps to the new correct place.

This is a decent default that avoids some problems, notably the fixed layer accidentally covering up important content. Still, it’s somewhat weird for the user. Thus Opera’s implementation does not entirely convince.


Android WebKit 3.2
Android 3.2

Android WebKit implements true fixed positioning: the layer stays in place no matter what the user does. It also zooms with the page. In theory, this is what we’d like to have everywhere.

Still, there are quite a few problems, especially on mobile phones. Many fixed layers built for desktop sites are crammed with stuff and assume a 1024 screen width. The user cannot ever access all of the content in such a fixed layer on Android because there’s no way of getting it in view.

It’s the closest emulation of desktop position: fixed available and it clearly shows why perfect emulation is not the correct answer.


BlackBerry PlayBook WebKit 2
PlayBook 2

The BlackBerry PlayBook also implements true fixed positioning, but handles the zoom use case slightly differently. The example layer scrolls horizontally with the page, but not vertically. Thus it has true fixed position while simultaneously allowing the user to view the entire fixed layer, including the parts that are off-screen at this zoom level.

All in all I like BlackBerry’s take best. No frills, just do what’s necessary.


Safari 5.0.1
iOS 5.0.1

Safari on iOS, finally, is the most ambitious in its treatment of position: fixed. Zoomed out it’s true fixed positioning. When zoomed in, Safari scrolls the fixed layer, but slower than the main page. This allows the user to inspect all parts of the layer, but I’m not sure what the point of the slower scrolling is.

The solution doesn’t always work very well. In the video it takes ages and ages to reach the fixed layer after zoom, which means the layer isn’t really fixed at all.

Now this imperfection could be forgiven if there are clear and compelling advantages to Apple’s implementation that are absent from BlackBerry’s, but I don’t really see any. I think Apple is being too ambitious here, and may backtrack a bit in the next iOS version.

Which implementation do you prefer? Do you see a clear advantage of Apple’s implementation over BlackBerry’s? (If you do, please provide a test page.)

This is the blog of Peter-Paul Koch, web developer, consultant, and trainer. You can also follow him on Twitter or Mastodon.
Atom RSS

If you like this blog, why not donate a little bit of money to help me pay my bills?



Comments are closed.

1 Posted by Mike on 20 December 2011 | Permalink

Interesting. Thanks for the videos, they really are the best way to demonstrate this kind of thing.

I prefer iOS's implementation actually. I like that it is "fixed" on the bottom and you can zoom in on content without having it interfere. The BB's is slightly annoying that it zooms the fixed bar as well. Did you notice how the text changed and was not visible for a second or two before you scrolled?

2 Posted by Brad Frost on 21 December 2011 | Permalink

Thanks for this!
A lot of your findings are similar to my own, which is good!

Thanks to the help of some other people, we were able to test on the Kindle Fire, Nook Color, WP7 (pre and post Mango) and more.

I'm glad we have two independent studies of this. The good folks on the jQuery Mobile team are also diving in deep into this. Good to see some progress being made.