Monday, March 15th, 2010

A Better Mobile Web; What else?

Category: Mobile

<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?

Related Content:

Posted by Dion Almaer at 10:41 am
9 Comments

++++-
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, 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.

Comment by jx12345 — March 16, 2010

I agree with Joeri: Mobile Web != iPhone/iPad

Comment by Skilldrick — March 17, 2010

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

Comment by kaisellgren — February 13, 2011

Leave a comment

You must be logged in to post a comment.