spacer

Monday, March 15th, 2010

A Better Mobile Web; What else?

Category: Mobilespacer

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?

Posted by Dion Almaer at 10:41 am
9 Comments

spacer spacer spacer spacer spacer
4.3 rating from 16 votes

9 Comments »

Comments feed TrackBack URI

I agree. Also they should create something like:

-webkit-viewport-hscroll
-webkit-viewport-vscroll

This way you could tell the “browser” which components were to scroll.

For instance maybe you wanted a horizontal scroll on a nav bar and a vertical scroll on content. You also could possibly want a fixed header and footer, etc.

Comment by doughboy — March 15, 2010

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?

Comment by Joeri — March 15, 2010

@brianleroux well, it’s a start, but a real fix would be better :P

Comment by karnius — March 15, 2010

Isn’t fixed positioning what Apple managed to do in that (yet unofficial and undocumented) PastryKit?

Comment by chicojobs — March 15, 2010

What do you expect to happen when the user zooms a page with fixed-position elements?

Comment by smfr — March 15, 2010

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?

Comment by ialexi — March 15, 2010

At the moment Mobile Safari freezes all dom manipulation during normal (full-page non-javascript) scrolling. The scripts are still executed, b

gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.