Fix Bouncy footer

[abub]

Currently, the footer bar could be implemented as a position : static or fixed. 'Fixed' always shows as bottom of page. Sergey sees some issue with 'fixed' so is switching to 'static', which Todd recommended as well.

a- what is exactly the problem with IE's support of fixed? We claim full support http://www.caniuse.com/#search=fixed

b- The jQM team is adopting fixed now.. and our page here is using 'fixed' too .. is that the new approach? http://mshare.akvelon.net:8184/metro/samples/jqm-public-demo/pages/header.html

lets document clear resolution here thanks,

[toddparker]

Hi Abu -

Although IE supports position:fixed, from my tests I don't think WP7 or 7.5 does. Can you confirm? I can see that the new fixed toolbars (link below) work great on IE9, but not Mango here on our test devices.

In any case, we're using position:fixed as our new official approach because it is so much better and pretty widely supported, but recently re-formulated the older dynamic re-position polyfill as an optional plugin that isn't part of the core jQM library but is documented here: http://jquerymobile.com/test/docs/toolbars/bars-fixed.html

Repo: https://github.com/filamentgroup/jQuery-Mobile-FixedToolbar-Legacy-Polyfill

Demo: http://filamentgroup.github.com/jQuery-Mobile-FixedToolbar-Legacy-Polyfill/

A grade support simply means that the device will get the full enhanced CSS and JS along with the AJAX navigation system. We're very clear that the quality of the A grade experience is completely dependent on the CSS capabilities of the device. In the case of WP7, it doesn't support CSS gradients (non-filter), keyframe animations or position:fixed so these particular features fall back safely.

From http://jquerymobile.com/gbs/

"We use a 3-level graded platform support system: A (full), B (full minus Ajax), C (basic). The visual fidelity of the experience is highly dependent on the CSS rendering capabilities of the device and platform so not all A grade experience will be pixel-perfect but that’s the nature of the web."

BTW - that link above doesn't render in a desktop browser. It's just unstyled HTML.

[abub]

Thanks Todd. Sergey told me about the polyfill a while back. He was waiting for a final decision by you guys before finalizing our options. Now that I see fixed, and previously we had static, I wasn't sure what is the final story.

Will check with IE folks once we hear from Sergey Thanks,

[sgrebnov]

Hi Todd, Abu

What we use in current version:

In our metro theme we use jQM v.1.0.1 which provides special logic to calculate footer position after scrolling. Our metro footer works fairly well except landscape mode and some ’jumps’.

My experiments with latest jqm version:

The latest jQM version (1.1.0-rc.1) uses CSS “position: fixed”. IE mobile doesn’t support this property so the footer is static and always displayed at the bottom of the page. For such browsers jqm provides special polyfill - https://github.com/filamentgroup/jQuery-Mobile-FixedToolbar-Legacy-Polyfill,

but it seems it is still not in final stage so it doesn’t work very well (worse than the version we use right now) http://mshare.akvelon.net:8184/metro/tests/basic/gallery/html/fixed.html

I can confirm that WP does not support position: fixed so we should decide what to do A. We can leave current implementation as is. But I think our theme should be based on the latest jqm version. B. We can replace "fixed" appbar with static one. C. We can work together to get polyfill working well.

@abub, @toddparker , let's discuss the options.

[abub]

we certainly should use the latest from jQuery. When can you update?

So the polyfill locates the header and footer at the absolute ends of the page, while our footer remains at the bottom of a view, moving along with the page. Is that why you say that our behavior is better Sergey? I think for websites it makes sense to have the footer and header fixed. but for our app I prefer having the sliding footers

Todd, I guess the polyfill does not aim to cover that scenario, is that correct? My understanding is that its done, but we can discuss making it support the option we are looking into. Is that what you meant Sergey? I

[toddparker]

I'm not sure what the difference in behavior is that you need but the polyfill should dynamically the header and footer similarly to 1.0. If it's not, we can loop in Scott Jehl to work with Sergey to refine the script. You should definitely use 1.1 though - it's much better.

filament filamentgroup.com | 102 south street #3 boston, ma 02111
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . todd.parker .: . todd@filamentgroup.com .: . (tel) 617.482.7120 (fax) 617.687.0212

On Apr 3, 2012, at 12:59 PM | April 3, 2012, Sergei Grebnov wrote:

Hi Todd, Abu

What we use in current version:

In our metro theme we use jQM v.1.0.1 which provides special logic to calculate footer position after scrolling. Our metro footer works fairly well except landscape mode and some ’jumps’.

My experiments with latest jqm version:

The latest jQM version (1.1.0-rc.1) uses CSS “position: fixed”. IE mobile doesn’t support this property so the footer is static and always displayed at the bottom of the page. For such browsers jqm provides special polyfill - https://github.com/filamentgroup/jQuery-Mobile-FixedToolbar-Legacy-Polyfill,

but it seems it is still not in final stage so it doesn’t work very well (worse than the version we use right now) http://mshare.akvelon.net:8184/metro/tests/basic/gallery/html/fixed.html

I can confirm that WP does not support position: fixed so we should decide what to do A. We can leave current implementation as is. But I think our theme should be based on the latest jqm version. B. We can replace "fixed" appbar with static one. C. We can work together to get polyfill working well.

@abub, @toddparker , let's discuss the options.

---

Reply to this email directly or view it on GitHub: https://github.com/sgrebnov/jqmobile-metro-theme/issues/6#issuecomment-4912304

[scottjehl]

hey there.

Happy to help refine the polyfill for WP support.

Currently, it just checks if the browser is blacklisted, and then attempts to make the feature work by using position: absolute instead of fixed. I have not needed any iOS-specific behavior to make it work, so it should be doable to get it working better in WP (in theory).

Even with absolute positioning in play, the header is positioned from the top of the page and the footer is positioned from the bottom. Headers are positioned the distance of the current scroll from the top, and footers are positioned the following distance from the bottom: document height - scroll distance - screen height. Can you let me know if one or both of these is off on WP?

Perhaps you could file an issue in the tracker for that plugin and we can hash out the details there? Can you describe how the polyfill currently behaves for a header and a footer?

For intended behavior, you can check out the polyfill on an iOS4 device. It tends to work a lot better than the old fixed toolbars did on that platform, and the new API is a nice improvement as well.

Thanks

[sgrebnov]

Hi @scottjehl, great, I'll take a look what particular goes wrong with polyfill on WP7 tomorrow. The previous fixed footer plugin worked better than the current version, will investigate why. Thank you,

[sgrebnov]

I have checked polyfill with jQM v.1.1.0.rc2. It seems to work on WP except it always has the same gap between footer and screen bottom. I have looked into implementation and it seems that position is calculated properly. For example in case of page height = screen height I see that footer bottom position is set to zero which is correct, but it is still displayed with the gap. So I think the issue is related to meta tag 'viewport' and the way WP7 scales/zooms page.

As a temporary fix I added CSS style to shift footer down:

@media screen and (device-height: 800px) and (orientation: portrait){ .ui-footer-fixed { margin-bottom: -33px; } }

The problem here is that the gap depends on where we ran our html - in IE mobile application or hosted browser (phonegap case). So the fix above works great for phonegap cordova but displayed a little bit lower than it should be in general WP7 IE mobile app.

To be continued...

[sgrebnov]

TODO for Sergei. Review the following issues (jqm public demo)

1. Incorrect footer and header positions after using 'Switch theme' button (WP only).
2. Header and footer don't refresh position after navigation (WP only). Main page->'Headers and footers': fixed toolbars don't refresh position during scrolling.