Implement position:fixed for iOS5

[toddparker]

For 1.0, we should layer in position:fixed for browsers that support it - iOS5 and BB5 for out fixed headers and footers. Hopefully, more to come.

[posabsolute]

Position fixed is in android 2.2 if I am not mistaken
http://kentbrewster.com/android-scroller/

[pascalchristian]

Tested on Droid Incredible android 2.2, position:fixed is indeed available.

[toddparker]

Overflow: scroll is now supported in iOS 5 beta2 so that's even better news. Things are looking up.

[posabsolute]

unfortunately this is not supported on android, even on android 2.3.3 from what I see http://code.google.com/p/android/issues/detail?id=2911

[toddparker]

I know, Android is going to be stuck with position:fixed for a long time to come based on how slow people can upgrade on that platform. Hopefully, the iOS feature will make everyone else step up their game.

[cburgdorf]

But this behaves correct even on android devices. Am I wrong? http://doctyper.com/#/post/archives/200808/fixed-positioning-on-mobile-safari/

[posabsolute]

The thing is, you can implement something similar to overflow scroll for android and iphone! Think about it the other way around, use position fixed for toolbars instead, and even android 2.2 will be supported,

if your going with overflow scroll the percentage of the android base users using it will be very slim since carrier rarely update the android os (when its available)

I think it would integrate well with the data-fixed, you could default to the old scheme in case position-fixed is not supported

[cburgdorf]

But why does jquery mobile fade out the bottom bar on scrolling and fades it in once the scrolling stops? I think I can't follow these detailed css stuff as I'm not THAT of a css guru but I really think the bottom and top bars should behave as in the posted link (visually, I don't care about the actual css which is needed to get there)

[cburgdorf]

Sorry, for bugging you but I still don't get it. What prevents us from applying the technique which is used in the link I posted. Because this works fine on android. Can't we just use this technique at least for android?

[toddparker]

To summarize: we'll probably use position: fixed for Android 2.2+ and either that or overflow:scroll in iOS 5. Ultimately, we need to feature test and target these features in a smart way, then fall back to the current positioning or simple inline toolbars in less capable browsers.

I think @posabsolute was thinking you were asking why we dynamically re-position, then fade in the toolbars at all. I read your response as thinking that poisiton:fixed was supported well on mobile browsers too.

The overflow property will also let us dramatically improve page transitions in iOS which is great.

[cburgdorf]

Indeed, I'm asking why we fade out /fade in the toolbars while scrolling. I mean, I would understand it if there was no way to implement it but then I stumbled over the link (see above) and this works fine on the android browser. Or does this only work for me because my device is already android 2.3. Unfortunatly I haven't tested the link with an android 2.2 device.

[cburgdorf]

@posabsolute Ah, ok. I didn't know that. Well, the use doesn't care how it works behind the scene. But if you say that its error prone I have to take that for granted ;-)

[scottjehl]

cburgdorf: In regards to the solution you linked: Generally, we're striving to keep things as lightweight functional across a very wide array of browsers, so we opted-out of simulating/fake scrolling with JavaScript early-on in favor of making the most of browsers' native scrolling. This has its own drawbacks, especially when you're trying to mimic native iOS app patterns, but the advantages in accessibility and usability that come with sticking to native scrolling satisfy the goals of this framework. We'll continue to evaluate solutions as they come out, but so far, we've yet to find a "fake" scroller that meets all of our needs (including targeting certain browsers and not others in a sustainable way).

There are other frameworks that put more attention into mimicking the native experience on iOS, so if that's what you're trying to do, we'd definitely suggest trying those out! :) If you'd like to implement fake/simulated scrolling to get truly fixed headers and footers, there are some newer scripts that you could try that should work pretty well in iOS and Android.

Scrollability is pretty popular, for one. I'm not sure if they offer any demos that fall back to real scrolling in non-mobile-webkit or desktop browsers, so if you're delivering your site/app via the web (as opposed to a native app), that could be a concern: http://joehewitt.github.com/scrollability/

That aside, we'll continue working on making our implementations smoother where available!

[cburgdorf]

Hi Scott, thanks for the follow up. It's not that big of an issue for me. I just thought I might have found something nobody was aware of ;-) stupid me! Keep up the good work!

[toddparker]

An alternate approach: use -webkit-scrolling-overflow: touch on the content area and just position the header and footer bars.

[negue]

1. Are there any example of http://kentbrewster.com/android-scroller/ that works with JQM? I could implement it, but it only works if i change to a inner page (with id) and then the header is fixed under android 2.2.. but I need this fixed header already onLoad (without switching to a inner page)
2. And -webkit-scrolling-overflow: touch don't works either.
3. the Current scrollview.js works on android 2.2, BUT it is really slow :(

[kpuputti]

Note that Android 2.2+ supports position: fixed, but you must set the viewport meta tag in a certain way ( http://caniuse.com/css-fixed ). This disables zoom, which JQM at least said earlier it doesn't want to do.

Is it worth disabling the zoom to get the functionality for Android?

[negue]

Thanks for the link.

Yes, we don't need the zoom functionality, so i'm okay with it.

Great, now the fixed header is fixed. (Best Implementation is the Boat Browser)

But now all native selectmenus don't opens, so I have to use the non-native ones.

[scottjehl]

I think at this point, we're looking to scope this feature to CSS "overflow-scrolling: touch" supporting browsers (currently, only in the iOS5 betas, but hopefully others will jump onboard), since this feature needs to be a combination of touch-safe CSS overflow and position: fixed support. Without overflow-scrolling support, we might be able to use fixed positioning , but regular overflow scrolling is just not safe to use for scrolling on mobile devices, since it requires 2 fingers on iOS, and renders content inaccessible on other platforms.

On Aug 16, 2011, at 9:17 AM | Aug 16, 2011, eugenb1 wrote:

Thanks for the link.

Yes, we don't need the zoom functionality, so i'm okay with it.

Great, now the fixed header is fixed. (Best Implementation is the Boat Browser)

But now all native selectmenus don't opens, so I have to use the non-native ones.

Reply to this email directly or view it on GitHub:
#1792 (comment)

[posabsolute]

What do you mean @scottjehl by "regular overflow scrolling is just not safe to use for scrolling on mobile devices"? Scrolling in the position fixed toolbar? This seems like a feature you do not have currently anyway..

Since your fixed toolbars are, well fixed, I would have think that position fixed is a match in heaven since you would have a "broad support" from the get go.

[scottjehl]

This just landed on HEAD! It's disabled by default. Since iOS5 is still in beta, it's not common yet. Here's how jQM will look as a result whenever the upgrade comes out. http://vimeo.com/28776692

[posabsolute]

Oh shit! (sorry for the useless comment)

[matthew-dean]

I just tested iOS5 with the demo, and the fixed toolbars weren't imitating the video. Is "auto-fixed" support coming later?

[toddparker]

It there, but disabled by default because iOS5 isn't yet released and we want to test this more. You can activate it by setting this global option:

touchOverflowEnabled boolean, default: false
Enable smoother page transitions and true fixed toolbars in devices that support both the overflow: and overflow-scrolling: touch; CSS properties.

http://jquerymobile.com/test/docs/api/globalconfig.html

[matthew-dean]

Oh, okay. I was using the Gold Master, same version released tomorrow. So, revisit this tomorrow?

Thanks for the tip to enable it.

[toddparker]

I don't think we're going to change the default until we get a fair amount of feedback/testing so this may be off even at 1.0. It all depends on timing and testing results. From what I've seen it works great, just being conservative.

Sent from my iPhone

On Oct 11, 2011, at 8:19 PM, "matthewdl" reply@reply.github.com wrote:

Oh, okay. I was using the Gold Master, same version released tomorrow. So, revisit this tomorrow?

Thanks for the tip to enable it.

Reply to this email directly or view it on GitHub:
#1792 (comment)

[gm90]

Hi Todd + all,

Just for some feedback I've enabled touchOverflowEnabled and it works really well as far as I can tell hopefully with some more feedback this can be something that is included by default.

Keep up the fantastic work.

Many thanks,
Gary