I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

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

Browser

Opera Mobile 11.50

OS

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

Browser

Android WebKit 3.2

OS

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

Browser

BlackBerry PlayBook WebKit 2

OS

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.

iOS

Browser

Safari 5.0.1

OS

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.)

Comments

Comments are closed.