<p>Cedric Dugas feels so passionate about fixed positioning in WebKit that he created A Better Mobile Web to talk about it:

The Problem

It is impossible to have an element fixed in CSS on the page in the mobile Webkit browser. When you are surfing the web on your phone, webkit opens the page completely and acts as a viewport.

“Imagine a book in front of you. Take a piece of paper, cut a 320*416 square in it, and lay it over the book. To read the book, move the paper around and position the hole over the words you want to see.” -Richard Herrera

Why it is important

To create better mobile applications and websites, we need fixed positionning to give the user better tools to browse the web on handled devices. Like a real mobile app, we could have a fixed toolbar when scrolling on a site, it is critical to not take the user in hostage in very long list or on long content pages. This is something we can’t really emulate in javascript as mobile devices are not really powerful.

The solution

The Webkit team could give us a proprietary CSS property that would overwrite the viewport behavior, and this is the proposition here. Give us a CSS property like position: -webkit-viewport-fixed that we can apply on a div so it can be fixed to the viewport.

That is one feature request, but surely there we can add to that? The broad domain of “abettermobileweb.com” deserves more!

What would you like to see for mobile specifically that isn’t covered in the current Web and device API standard work?

How about pushing for more standardization across mobile browsers and devices? I’m sick and tired of the iphone being considered the only mobile device worthy of attention. I’m also tired of getting locked out of mobile apps that could have been built just as well in a cross-device way.
.
What I want is a decent baseline browsing level, with standardized mobile API’s (viewport, …), and with high-quality W3C widget support (again, with good API’s for accessing device functionality). 95 percent of the iphone apps could have been built as W3C widgets on a decently implemented widget runtime. It”s very sad that mobile development is going through all the same mistakes that desktop development went through. It took a decade for the desktop web to become usable as a development platform. Will it also take a decade for the mobile web?

PastryKit does it by implementing scrolling through code. This is also the most flexible way to do it. It can also be very high performance, assuming you use -webkit-transform: translate3d to position the scrolling view, as this uses GPU acceleration.

If WebKit were to offer it natively, however, I’d suggest not so much fixed elements, as scrollable elements. As suggested, overflow: -webkit-viewport-hscroll, etc., is ok, but how about also having -webkit-scroll-deceleration to change the rate of scrolling?

At the moment Mobile Safari freezes all dom manipulation during normal (full-page non-javascript) scrolling. The scripts are still executed, bet anything that changes the dom, is postponed after the scrolling has ended. And it makes sense to use all resources for a smooth scrolling animation, because 99% of the time you won’t event notice that the dom gets frozen for a moment. Scrolling text is the most common example where this can be seen, but even that doesn’t deter the overall browsing experience.

The moment there’s a fixed element on the page, the dom must be manipulated during the scrolling – that means a reflow on every pixel of scroll movement. So – until there’s really powerful hardware accelerated css transitions or a way to sandbox reflows, I don’t see this implemented in Mobile Safari. I’m sure they’ll fix it at some point (and make a huge deal about it), but for now we’ll have to live without it.

@smfr: I would expect it to zoom the fixed element also and position it properly as the content would. So, if you have a table with a list of entries and a fixed header, a zoom would also zoom the header and position it properly with the list.

The only problem here is that it can not be the default behavior for position: fixed because it would break many websites for the second reason: when zoomed enough it will make the site unusable.

The unusability can be only solved by the developer mostly as he knows the software. Let us give him events such as “zoom” that gives him the level of zoom and then he can decide when the user has zoomed too much and he can just fade out the fixed element.