New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch fixed toolbars to CSS position:fixed #3216

Closed
toddparker opened this Issue Dec 5, 2011 · 96 comments

Comments

Projects
None yet
@toddparker
Contributor

toddparker commented Dec 5, 2011

Issue #1792 was originally opened to move away from the dynamically positioned (via JS) toolbars to use position:fixed but at the time, we decided to pursue the touchOverflow approach because it made fixed toolbars and smoother transitions happen, if only in iOS5 for now.

Brad Frost recently did a fresh batch of testing and re-thinking the use of native position:fixed is warranted because not only does it give us "true" fixed toolbars with minimal code, it is surprisingly well supported and mostly falls back to inline positioning. The worst case scenario is that in some browsers (BB6, Android 2.1), the toolbars scroll with the page before re-positioning themselves but this isn't much different than our current JS-based solution.

Brad's results:
http://bradfrostweb.com/blog/mobile/fixed-position/

Our testing of his pages for both position:fixed and overflow:
https://github.com/jquery/jquery-mobile/wiki/Position:fixed-and-Overflow:-testing

Native overflow is more difficult to use for two reasons: on some browsers, overflow content is clipped off and inaccessible or requires a two finger scroll, and even when it works, performance can be slow.

If we switch to using position:fixed, we would need to disable user zoom to make this kick in for Android. It also makes it a bit easier to use across the board because it's easy to get into odd zoom scenarios where the fixed toolbars take up the whole screen and other usability issues. This is a case where the tradeoffs seems acceptable if you opt into fixed toolbars.

We expect to have true fixed toolbars working on following platforms:

  • iOS 5
  • Android 2.2, 2.3, 3.0 (honeycomb), 4.0 (Ice cream sandwich)
  • Blackberry 7 (BB6 re-positions fixed after scroll stops, like our JS solution)
  • PlayBook
  • Firefox mobile 6
  • WebOS 2+
  • Kindle Fire
  • Kindle 3
  • Nook Color 1 & 2 (tablet)
  • All modern desktop browsers (Safari, Firefox, Opera, Chrome, IE, etc.)

Most other platforms will simply fall back to inline positioning. There are a few platforms that may half-support this feature and may incorrectly position the toolbars so we'll need to keep an eye out to see if we need to manually exclude these if they aren't usable:

  • Android 2.1
  • Blackberry 5
  • Opera Mobile

A few technical things to keep in mind:

  • Since the fixed toolbars will be absolutely positioned, we need to account for the height of the toolbars and add equivalent top/bottom margins on the content area to keep the content from being obscured by the toolbars in normal fixed mode (fullscreen mode does this intentionally).
  • We might also want to set a minimum screen height to use this feature because some Blackberries have small screens and toolbars could take up more that 50% of the height. If could be a simple rule that we don't active this unless the total height of fixed headers and footers are less than % of the height.
  • We will also keep the option to tap the screen to switch between fixed and inline toolbars, like the current fixed demo illustrates. Fullscreen toolbars actually tap to hide/show the toolbars.
  • We might want to add in an option to either show by default, hide by default or show initially but hide after X seconds.
@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 5, 2011

Contributor

This is being worked on by @garann in the dialog refactor branch right now, looking promising.

Contributor

toddparker commented Dec 5, 2011

This is being worked on by @garann in the dialog refactor branch right now, looking promising.

@scottjehl

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Dec 5, 2011

Contributor

Will we still include JS to control the logic for tap-toggling the visibility of the toolbars?

To my memory, this behavior constituted a large portion of this plugin's logic, and was unrelated to the absolute positioning part (which I agree sounds fine as position: fixed, assuming it doesn't fall apart in any popular fixed-unsupporting browsers).

Thx!

On Dec 5, 2011, at 9:19 AM, Todd Parker wrote:

Issue #1792 was originally opened to move away from the dynamically positioned (via JS) toolbars to use position:fixed but at the time, we decided to pursue the touchOverflow approach because it made fixed toolbars and smoother transitions happen, if only in iOS5 for now.

Brad Frost recently did a fresh batch of testing and re-thinking the use of native position:fixed is warranted because not only does it give us "true" fixed toolbars with minimal code, it is surprisingly well supported and mostly falls back to inline positioning. The worst case scenario is that in some browsers (BB6, Android 2.1), the toolbars scroll with the page before re-positioning themselves but this isn't much different than our current JS-based solution.


Reply to this email directly or view it on GitHub:
#3216

Contributor

scottjehl commented Dec 5, 2011

Will we still include JS to control the logic for tap-toggling the visibility of the toolbars?

To my memory, this behavior constituted a large portion of this plugin's logic, and was unrelated to the absolute positioning part (which I agree sounds fine as position: fixed, assuming it doesn't fall apart in any popular fixed-unsupporting browsers).

Thx!

On Dec 5, 2011, at 9:19 AM, Todd Parker wrote:

Issue #1792 was originally opened to move away from the dynamically positioned (via JS) toolbars to use position:fixed but at the time, we decided to pursue the touchOverflow approach because it made fixed toolbars and smoother transitions happen, if only in iOS5 for now.

Brad Frost recently did a fresh batch of testing and re-thinking the use of native position:fixed is warranted because not only does it give us "true" fixed toolbars with minimal code, it is surprisingly well supported and mostly falls back to inline positioning. The worst case scenario is that in some browsers (BB6, Android 2.1), the toolbars scroll with the page before re-positioning themselves but this isn't much different than our current JS-based solution.


Reply to this email directly or view it on GitHub:
#3216

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 5, 2011

Contributor

The plan is to keep the tap to toggle so it would go from fixed to inline, like it does today. Garann and I were talking an hour ago in irc about the details.

Since fixed is pos:absolute, we need to measure the height of headers and footers and add that as a top/bottom margin on the content block to keep proper spacing.

Think that whole plugin could be simplified with this change.

Contributor

toddparker commented Dec 5, 2011

The plan is to keep the tap to toggle so it would go from fixed to inline, like it does today. Garann and I were talking an hour ago in irc about the details.

Since fixed is pos:absolute, we need to measure the height of headers and footers and add that as a top/bottom margin on the content block to keep proper spacing.

Think that whole plugin could be simplified with this change.

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 5, 2011

Contributor

I was actually thinking we might want to automatically shut off fixed toolbars if they are more than 40-50% of the screen heights on these don't suck on small screens.

Contributor

toddparker commented Dec 5, 2011

I was actually thinking we might want to automatically shut off fixed toolbars if they are more than 40-50% of the screen heights on these don't suck on small screens.

@scottjehl

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Dec 5, 2011

Contributor

Sounds great - that was all I wondered about it. :)

On Dec 5, 2011, at 12:43 PM, Todd Parker wrote:

I was actually thinking we might want to automatically shut off fixed toolbars if they are more than 40-50% of the screen height son these don't suck on small screens.

.................................. . . . .
Todd Parker
Partner, Filament Group Inc.
102 South Street #3 Boston, MA 02111
todd@filamentgroup.com // 617.953.1617

On Dec 4, 2011, at 8:46 PM, "Scott Jehl" reply@reply.github.com wrote:

Will we still include JS to control the logic for tap-toggling the visibility of the toolbars?

To my memory, this behavior constituted a large portion of this plugin's logic, and was unrelated to the absolute positioning part (which I agree sounds fine as position: fixed, assuming it doesn't fall apart in any popular fixed-unsupporting browsers).

Thx!

On Dec 5, 2011, at 9:19 AM, Todd Parker wrote:

Issue #1792 was originally opened to move away from the dynamically positioned (via JS) toolbars to use position:fixed but at the time, we decided to pursue the touchOverflow approach because it made fixed toolbars and smoother transitions happen, if only in iOS5 for now.

Brad Frost recently did a fresh batch of testing and re-thinking the use of native position:fixed is warranted because not only does it give us "true" fixed toolbars with minimal code, it is surprisingly well supported and mostly falls back to inline positioning. The worst case scenario is that in some browsers (BB6, Android 2.1), the toolbars scroll with the page before re-positioning themselves but this isn't much different than our current JS-based solution.


Reply to this email directly or view it on GitHub:
#3216


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


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

Contributor

scottjehl commented Dec 5, 2011

Sounds great - that was all I wondered about it. :)

On Dec 5, 2011, at 12:43 PM, Todd Parker wrote:

I was actually thinking we might want to automatically shut off fixed toolbars if they are more than 40-50% of the screen height son these don't suck on small screens.

.................................. . . . .
Todd Parker
Partner, Filament Group Inc.
102 South Street #3 Boston, MA 02111
todd@filamentgroup.com // 617.953.1617

On Dec 4, 2011, at 8:46 PM, "Scott Jehl" reply@reply.github.com wrote:

Will we still include JS to control the logic for tap-toggling the visibility of the toolbars?

To my memory, this behavior constituted a large portion of this plugin's logic, and was unrelated to the absolute positioning part (which I agree sounds fine as position: fixed, assuming it doesn't fall apart in any popular fixed-unsupporting browsers).

Thx!

On Dec 5, 2011, at 9:19 AM, Todd Parker wrote:

Issue #1792 was originally opened to move away from the dynamically positioned (via JS) toolbars to use position:fixed but at the time, we decided to pursue the touchOverflow approach because it made fixed toolbars and smoother transitions happen, if only in iOS5 for now.

Brad Frost recently did a fresh batch of testing and re-thinking the use of native position:fixed is warranted because not only does it give us "true" fixed toolbars with minimal code, it is surprisingly well supported and mostly falls back to inline positioning. The worst case scenario is that in some browsers (BB6, Android 2.1), the toolbars scroll with the page before re-positioning themselves but this isn't much different than our current JS-based solution.


Reply to this email directly or view it on GitHub:
#3216


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


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

@woutervanwijk

This comment has been minimized.

Show comment
Hide comment
@woutervanwijk

woutervanwijk Dec 5, 2011

Sound good to me. The toolbars don't work very well right now, especially the fixed ones. I like the way it's implemented on the mobile site of seeekingalpha.com

woutervanwijk commented Dec 5, 2011

Sound good to me. The toolbars don't work very well right now, especially the fixed ones. I like the way it's implemented on the mobile site of seeekingalpha.com

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 12, 2011

Contributor

According to Google, this technique will work in 85-90% of Android devices as of Dec. 2011 (2.2, 2.3, 3.0):
http://developer.android.com/resources/dashboard/platform-versions.html

It will be interesting to see iOS5 % vs older versions.

Contributor

toddparker commented Dec 12, 2011

According to Google, this technique will work in 85-90% of Android devices as of Dec. 2011 (2.2, 2.3, 3.0):
http://developer.android.com/resources/dashboard/platform-versions.html

It will be interesting to see iOS5 % vs older versions.

@ghost ghost assigned scottjehl Dec 12, 2011

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 14, 2011

Contributor

Initial testing is very promising. We're now working on a support test to decide which browsers should get the fixed:rules. Ideally, we can write a test to opt out the handful of browsers that claim to support this, but end up incorrectly positioning the bars over the content instead of falling back to static positioning.

The current test is based on Kangax's fixed position feature test. We're going to look at adding with some tweaks based on Modernizr's test to resolve an error in IE7 with the Kangax test.
http://kangax.github.com/cft/#IS_POSITION_FIXED_SUPPORTED

This test page runs our current fixed: support test and adds a row with the result for each unique UA it finds:
http://filamentgroup.com/tests/fixedtest/

The most important platform caught by this test is older versions of iOS (pre-5) what incorrectly drop the toolbars over the content then scroll them with the document.

We currently have a few false positives in the Kangax test where it passes the test, but crashes and burns on positioning. We've been working on trying to detect the positioning issues to fail these browsers, but it seems like they are reporting the right values, but rendering them wrong so it may be hard/impossible to write a support test eliminate all the browsers cleanly.

The browsers that currently pass the test but fail on rendering correctly are:

  • Android 2.1
  • Opera Mobile (less than 11.0, 11.5 works but dynamically re-positions instead of true fixed)
  • Opera Mini (latest)
  • Firefox mobile (latest)

We also might want to exclude Blackberry 6 from this feature because it dynamically re-postions the toolbars when you scroll and it looks really bad. Falling back to static would be preferable in an browser that re-positions the toolbars when a :fixed rule is in play.

To see this issues with these browsers, view this link and scroll the page:
http://wil.to/fixed/

Contributor

toddparker commented Dec 14, 2011

Initial testing is very promising. We're now working on a support test to decide which browsers should get the fixed:rules. Ideally, we can write a test to opt out the handful of browsers that claim to support this, but end up incorrectly positioning the bars over the content instead of falling back to static positioning.

The current test is based on Kangax's fixed position feature test. We're going to look at adding with some tweaks based on Modernizr's test to resolve an error in IE7 with the Kangax test.
http://kangax.github.com/cft/#IS_POSITION_FIXED_SUPPORTED

This test page runs our current fixed: support test and adds a row with the result for each unique UA it finds:
http://filamentgroup.com/tests/fixedtest/

The most important platform caught by this test is older versions of iOS (pre-5) what incorrectly drop the toolbars over the content then scroll them with the document.

We currently have a few false positives in the Kangax test where it passes the test, but crashes and burns on positioning. We've been working on trying to detect the positioning issues to fail these browsers, but it seems like they are reporting the right values, but rendering them wrong so it may be hard/impossible to write a support test eliminate all the browsers cleanly.

The browsers that currently pass the test but fail on rendering correctly are:

  • Android 2.1
  • Opera Mobile (less than 11.0, 11.5 works but dynamically re-positions instead of true fixed)
  • Opera Mini (latest)
  • Firefox mobile (latest)

We also might want to exclude Blackberry 6 from this feature because it dynamically re-postions the toolbars when you scroll and it looks really bad. Falling back to static would be preferable in an browser that re-positions the toolbars when a :fixed rule is in play.

To see this issues with these browsers, view this link and scroll the page:
http://wil.to/fixed/

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 14, 2011

Contributor

We had a crazy idea to try and use position:fixed to simulate overflow panels. When you touch the left panel to scroll, it clips and sets the right panel to position: fixed. We flip this when you try scrolling the right. It works in theory but is pretty buggy in practice, but worth the experiment: http://jsbin.com/ituris/65

Contributor

toddparker commented Dec 14, 2011

We had a crazy idea to try and use position:fixed to simulate overflow panels. When you touch the left panel to scroll, it clips and sets the right panel to position: fixed. We flip this when you try scrolling the right. It works in theory but is pretty buggy in practice, but worth the experiment: http://jsbin.com/ituris/65

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 16, 2011

Contributor

[ Here is an update from @scottjehl on his latest progress and new fixed branch ]

Okay so, first off, Mat and I wrote a pretty good feature test for position:fixed support, but unfortunately, it was pretty obtrusive (scrolling the window), and also gave inaccurate results in Android 2.1 – maybe some others too.

For these reasons, I’m now trying to build the feature to be enabled for all, and then opt-out a few troublesome browsers with brute force (read: browser detection. I know, I know…).

So, on the topic of that feature that’s enabled for all:

I just pushed a big update to the new css-fixed branch that begins work on porting the fixed toolbars feature over to CSS positioning. The branch contains a draft of a full rewrite of the fixed toolbars feature, which I think is good because there’s a lot of hard-to-understand cruft in the current one.

Here’s a list of changes in place so far:

  • I removed both jquery.mobile.fixHeaderFooter.js and jquery.mobile.fixHeaderFooter.native.js and added a new file “jquery.mobile.fixedToolbars”, which contains the new behavior.
  • I moved all of the CSS related to this feature to jquery.mobile.headerfooter.css file, so it no longer has remnants in Core CSS.
  • In iOS5, the feature works great for me. However, I’ve removed the iOS5-specific CSS touch-overflow handling from this plugin entirely, as it’s not needed for fixed positioning to work. It’s currently just using the default browser scrolling, which is nice because the momentum feels more natural than the overflow version. However, this change would mean that the transitions jump to top again in iOS5, rather than pinning in place, but I’m planning to tackle a change to transitions next that should make that problem go away (we’ll be prototyping a different transition style next that won’t need overflow support). Anyway, transitions aside, if we want to keep overflow-scrolling support in there, we can add the feature back again to a core file, since it’s unrelated to this plugin. It’s as simple as a class addition and a few lines of CSS.
  • The plugin still supports both regular fixed toolbars and “fullscreen” toolbars (which overlay content, even when scrolled to the top or bottom), though it now allows the data-fullscreen attribute to be on the header itself, in addition to the page div, which we supported before.
  • When the toolbars are fixed, but not “fullscreen”, the page div has top and bottom padding to accommodate the toolbar heights that are not there. This padding amount will likely need to be dynamically updated on load, resize, and though a manual method devs can use (ugh).
  • Since page zooming can cause usability issues with fixed positioned elements, I’ve wired up the plugin to disable user zoom whenever a fixed toolbar page is active, but then reset the user zoom settings to whatever configuration it was in before, after the page is hidden again. (This currently has a bug in the reset part, but you can at least see that most of the docs are zoomable, but then you can’t zoom into the fixed toolbars page).
  • The new plugin is written using the widget factory, which will make for easier testing and extension points, as well as options and methods support.
  • This also means that the plugin is called per-toolbar, rather than per-page. I’m seeing some great benefits to this already, both organizationally for us, and for configuration.

The following options are preliminarily supported:

  • visibleOnPageShow: boolean for whether a toolbar should be visible when its page is shown
  • togglePageZoom: if true, the plugin will disabled page zooming when the toolbar is visible
  • transition: the transition for showing and hiding the toolbars. Currently it’s set to “fade”. “slide” also works, and slides the bars up and down from the vertical edges of the screen. This option can also be false, for no transition.
  • fullscreen: boolean, formerly only a data attribute, which allows for “fullscreen” overlay toolbars
  • tapToggle: tap to show and hide the toolbars. Preliminary support is in place, and enabled for testing purposes. Note that this feature probably should not work if the user is scrolled to the top of the page and the toolbars are not “fullscreen”. Otherwise it just hides and leaves whitespace, which is odd.
  • scrollToggle: show and hide the toolbars during scroll. This isn’t quite working yet, and in hindsight, I should probably pull it out and replace it with an option for “hideonScrollstop, which hides the toolbars when you STOP scrolling, allowing you to bring them back again with a tap. The NYTimes iOS app does this and it’s pretty nice. The code weight would only be a few lines for that feature.
  • supportBlacklist: the dreaded browser detect blacklist! So far, I’ve opted out iOS versions older than 5 (please verify), and Opera Mini. I still need to add detection for Android webkit older than 2.2. Since this is an option, people can improve it or remove it too, or try to polyfill it, which is nice. We should do some spoof-testing on this too, especially on BB!
  • initSelector: defaults to‘)”, for auto-initializing. The plugin auto-inits on pagecreate and create, like most others.

The following methods are also supported:

  • show: show the toolbar
  • hide: hide the toolbar
  • toggle: toggle the toolbar
  • destroy: just for class removal so far
  • disablePageZoom: the function used internally for disabling user zoom. This may be best left private, we’ll see.
  • restorePageZoom: opposite of above. Again, should probably be private.

I’ve posted a demo of the branch so we can begin testing it as I work on bugs and unit tests. The tapToggle option is enabled, just for fun, but I’d imagine it’ll be off by default (yes?).

http://filamentgroup.com/tests/jqm-nativefixed/

Contributor

toddparker commented Dec 16, 2011

[ Here is an update from @scottjehl on his latest progress and new fixed branch ]

Okay so, first off, Mat and I wrote a pretty good feature test for position:fixed support, but unfortunately, it was pretty obtrusive (scrolling the window), and also gave inaccurate results in Android 2.1 – maybe some others too.

For these reasons, I’m now trying to build the feature to be enabled for all, and then opt-out a few troublesome browsers with brute force (read: browser detection. I know, I know…).

So, on the topic of that feature that’s enabled for all:

I just pushed a big update to the new css-fixed branch that begins work on porting the fixed toolbars feature over to CSS positioning. The branch contains a draft of a full rewrite of the fixed toolbars feature, which I think is good because there’s a lot of hard-to-understand cruft in the current one.

Here’s a list of changes in place so far:

  • I removed both jquery.mobile.fixHeaderFooter.js and jquery.mobile.fixHeaderFooter.native.js and added a new file “jquery.mobile.fixedToolbars”, which contains the new behavior.
  • I moved all of the CSS related to this feature to jquery.mobile.headerfooter.css file, so it no longer has remnants in Core CSS.
  • In iOS5, the feature works great for me. However, I’ve removed the iOS5-specific CSS touch-overflow handling from this plugin entirely, as it’s not needed for fixed positioning to work. It’s currently just using the default browser scrolling, which is nice because the momentum feels more natural than the overflow version. However, this change would mean that the transitions jump to top again in iOS5, rather than pinning in place, but I’m planning to tackle a change to transitions next that should make that problem go away (we’ll be prototyping a different transition style next that won’t need overflow support). Anyway, transitions aside, if we want to keep overflow-scrolling support in there, we can add the feature back again to a core file, since it’s unrelated to this plugin. It’s as simple as a class addition and a few lines of CSS.
  • The plugin still supports both regular fixed toolbars and “fullscreen” toolbars (which overlay content, even when scrolled to the top or bottom), though it now allows the data-fullscreen attribute to be on the header itself, in addition to the page div, which we supported before.
  • When the toolbars are fixed, but not “fullscreen”, the page div has top and bottom padding to accommodate the toolbar heights that are not there. This padding amount will likely need to be dynamically updated on load, resize, and though a manual method devs can use (ugh).
  • Since page zooming can cause usability issues with fixed positioned elements, I’ve wired up the plugin to disable user zoom whenever a fixed toolbar page is active, but then reset the user zoom settings to whatever configuration it was in before, after the page is hidden again. (This currently has a bug in the reset part, but you can at least see that most of the docs are zoomable, but then you can’t zoom into the fixed toolbars page).
  • The new plugin is written using the widget factory, which will make for easier testing and extension points, as well as options and methods support.
  • This also means that the plugin is called per-toolbar, rather than per-page. I’m seeing some great benefits to this already, both organizationally for us, and for configuration.

The following options are preliminarily supported:

  • visibleOnPageShow: boolean for whether a toolbar should be visible when its page is shown
  • togglePageZoom: if true, the plugin will disabled page zooming when the toolbar is visible
  • transition: the transition for showing and hiding the toolbars. Currently it’s set to “fade”. “slide” also works, and slides the bars up and down from the vertical edges of the screen. This option can also be false, for no transition.
  • fullscreen: boolean, formerly only a data attribute, which allows for “fullscreen” overlay toolbars
  • tapToggle: tap to show and hide the toolbars. Preliminary support is in place, and enabled for testing purposes. Note that this feature probably should not work if the user is scrolled to the top of the page and the toolbars are not “fullscreen”. Otherwise it just hides and leaves whitespace, which is odd.
  • scrollToggle: show and hide the toolbars during scroll. This isn’t quite working yet, and in hindsight, I should probably pull it out and replace it with an option for “hideonScrollstop, which hides the toolbars when you STOP scrolling, allowing you to bring them back again with a tap. The NYTimes iOS app does this and it’s pretty nice. The code weight would only be a few lines for that feature.
  • supportBlacklist: the dreaded browser detect blacklist! So far, I’ve opted out iOS versions older than 5 (please verify), and Opera Mini. I still need to add detection for Android webkit older than 2.2. Since this is an option, people can improve it or remove it too, or try to polyfill it, which is nice. We should do some spoof-testing on this too, especially on BB!
  • initSelector: defaults to‘)”, for auto-initializing. The plugin auto-inits on pagecreate and create, like most others.

The following methods are also supported:

  • show: show the toolbar
  • hide: hide the toolbar
  • toggle: toggle the toolbar
  • destroy: just for class removal so far
  • disablePageZoom: the function used internally for disabling user zoom. This may be best left private, we’ll see.
  • restorePageZoom: opposite of above. Again, should probably be private.

I’ve posted a demo of the branch so we can begin testing it as I work on bugs and unit tests. The tapToggle option is enabled, just for fun, but I’d imagine it’ll be off by default (yes?).

http://filamentgroup.com/tests/jqm-nativefixed/

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 16, 2011

Contributor

Awesome work Mr. Jehl. So far, testing has gone really well on the link above. There are two issues I've seen so far:

  • The tap to toggle interferes with the select element and many other widgets. When I click the select, it toggles the toolbars instead of activating the select. On iOS 5, it toggles the toolbars then opens the select but on Android, the first tap toggles the toolbars and you need to click again to open the select.
  • When you tap to hide, as you mentioned above, you end up with a blank slot. Could we just not hide a toolbar that is visible in the viewport if you're looking at this in non-fullscreen mode? Think that's how it works currently
Contributor

toddparker commented Dec 16, 2011

Awesome work Mr. Jehl. So far, testing has gone really well on the link above. There are two issues I've seen so far:

  • The tap to toggle interferes with the select element and many other widgets. When I click the select, it toggles the toolbars instead of activating the select. On iOS 5, it toggles the toolbars then opens the select but on Android, the first tap toggles the toolbars and you need to click again to open the select.
  • When you tap to hide, as you mentioned above, you end up with a blank slot. Could we just not hide a toolbar that is visible in the viewport if you're looking at this in non-fullscreen mode? Think that's how it works currently
@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 16, 2011

Contributor

I just did a quick scan on key platforms to summarize our testing results so far:

Confirmed support = true fixed toolbars with native scrolling

  • Playbook
  • BB7
  • Nook
  • Kindle Fire
  • Kindle 3 (!)
  • iOS5 - iPhone and iPad
  • Android Honeycomb tablets
  • Android 2.2 and 2.3

Safely falls back to static positionering naturally or through current test/blacklist

  • iOS 3-4
  • WP 7-7.5
  • Android 1.5-1.6
  • Blackberry 4-5
  • WebOS 1.4

Still to be excluded, impacts usability - listed by importance

  • BB6 - toolbars reposition (sometimes) after scroll, but seems to impact scrolling performance
  • BB5 - toolbars reposition many times during scroll so jittery, footer positioning is about 10px too high
  • Android 2.1 - toolbars are positioned over the content
  • Opera Mobile - version 11.5 sort of re-positions after scroll, but cleaner to exclude all versions
  • Opera Mini - tested ib 6.5 (latest) but exclude all versions
  • Bada Dolphin - toolbars are positioned over the content
  • Firefox mobile - re-positions after scroll, could keep but it's not an ideal experience
  • WebOS 3/TouchPad - re-positions after scroll, could keep but it's not an ideal experience
Contributor

toddparker commented Dec 16, 2011

I just did a quick scan on key platforms to summarize our testing results so far:

Confirmed support = true fixed toolbars with native scrolling

  • Playbook
  • BB7
  • Nook
  • Kindle Fire
  • Kindle 3 (!)
  • iOS5 - iPhone and iPad
  • Android Honeycomb tablets
  • Android 2.2 and 2.3

Safely falls back to static positionering naturally or through current test/blacklist

  • iOS 3-4
  • WP 7-7.5
  • Android 1.5-1.6
  • Blackberry 4-5
  • WebOS 1.4

Still to be excluded, impacts usability - listed by importance

  • BB6 - toolbars reposition (sometimes) after scroll, but seems to impact scrolling performance
  • BB5 - toolbars reposition many times during scroll so jittery, footer positioning is about 10px too high
  • Android 2.1 - toolbars are positioned over the content
  • Opera Mobile - version 11.5 sort of re-positions after scroll, but cleaner to exclude all versions
  • Opera Mini - tested ib 6.5 (latest) but exclude all versions
  • Bada Dolphin - toolbars are positioned over the content
  • Firefox mobile - re-positions after scroll, could keep but it's not an ideal experience
  • WebOS 3/TouchPad - re-positions after scroll, could keep but it's not an ideal experience
@commadelimited

This comment has been minimized.

Show comment
Hide comment
@commadelimited

commadelimited Dec 16, 2011

Contributor

Thanks for all the hard work guys. I've spoken about jQuery Mobile to hundreds of people at conferences and user groups and this is one question that comes up time and time again. Thanks for making it happen.

Contributor

commadelimited commented Dec 16, 2011

Thanks for all the hard work guys. I've spoken about jQuery Mobile to hundreds of people at conferences and user groups and this is one question that comes up time and time again. Thanks for making it happen.

@scottjehl

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Dec 17, 2011

Contributor

Hey Todd,
Thanks for pasting my email in. I'm glad to hear testing is going so well!

For review so far, here's the JS for the plugin: https://github.com/jquery/jquery-mobile/blob/css-fixed/js/jquery.mobile.fixedToolbar.js
And the CSS: https://github.com/jquery/jquery-mobile/blob/css-fixed/css/structure/jquery.mobile.headerfooter.css

On my note about dynamically adjusting the padding above, I think it might be better to just leave it to developers to adjust the padding based on their content and toobar height. Just seems really fussy to bind to events and keep recalculating it.

Contributor

scottjehl commented Dec 17, 2011

Hey Todd,
Thanks for pasting my email in. I'm glad to hear testing is going so well!

For review so far, here's the JS for the plugin: https://github.com/jquery/jquery-mobile/blob/css-fixed/js/jquery.mobile.fixedToolbar.js
And the CSS: https://github.com/jquery/jquery-mobile/blob/css-fixed/css/structure/jquery.mobile.headerfooter.css

On my note about dynamically adjusting the padding above, I think it might be better to just leave it to developers to adjust the padding based on their content and toobar height. Just seems really fussy to bind to events and keep recalculating it.

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 17, 2011

Contributor

What if we just set padding once and then we can document how you should recac manually if you change the height of the toolbars?

Also curious whether we should use margin instead do the padding is consistent between pages using fixed and those without?

Contributor

toddparker commented Dec 17, 2011

What if we just set padding once and then we can document how you should recac manually if you change the height of the toolbars?

Also curious whether we should use margin instead do the padding is consistent between pages using fixed and those without?

@scottjehl

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Dec 17, 2011

Contributor

Yep - agreed on setting it once (in CSS, as it is now, ya?). Unless the toolbar has elements that reflow to change the height, once should be adequate.

re: margin: The padding is set on the page element, which normally has none. https://github.com/jquery/jquery-mobile/blob/css-fixed/css/structure/jquery.mobile.headerfooter.css#L25 Margin wouldn't be as good here, as I think we need the page to fill the dimensions of the screen.

For "fullscreen" toolbars, I've got a rule in there that removes all padding on the content div, under the assumption that people would use this feature mostly for full-screen photos and such. It's easy enough to override that if you need different padding though.

Contributor

scottjehl commented Dec 17, 2011

Yep - agreed on setting it once (in CSS, as it is now, ya?). Unless the toolbar has elements that reflow to change the height, once should be adequate.

re: margin: The padding is set on the page element, which normally has none. https://github.com/jquery/jquery-mobile/blob/css-fixed/css/structure/jquery.mobile.headerfooter.css#L25 Margin wouldn't be as good here, as I think we need the page to fill the dimensions of the screen.

For "fullscreen" toolbars, I've got a rule in there that removes all padding on the content div, under the assumption that people would use this feature mostly for full-screen photos and such. It's easy enough to override that if you need different padding though.

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 17, 2011

Contributor

Agreed that setting it once is good enough. Though I think we need to use JS to measure and set the padding based on the actual toolbar height since that could be quite variable. That what you had in mind? We could then offer a way to trigger a re-calc programmatically.

Setting the padding on the page is a great idea, same effect as margin on content but better. I just wanted to leave padding in content area alone so we're good.

Yep, full screen should work as described. I was just saying that we could not hide a normal fixed toolbar if you tap and you're at the top/bottom to avoid the blank space.

Contributor

toddparker commented Dec 17, 2011

Agreed that setting it once is good enough. Though I think we need to use JS to measure and set the padding based on the actual toolbar height since that could be quite variable. That what you had in mind? We could then offer a way to trigger a re-calc programmatically.

Setting the padding on the page is a great idea, same effect as margin on content but better. I just wanted to leave padding in content area alone so we're good.

Yep, full screen should work as described. I was just saying that we could not hide a normal fixed toolbar if you tap and you're at the top/bottom to avoid the blank space.

@negue

This comment has been minimized.

Show comment
Hide comment
@negue

negue Dec 19, 2011

Contributor

Great!

True Fixed Toolbars works on Samsung Galaxy Tab (Android 2.2)

But the z-index of the Switch-Control is higher than the Toolbars.

Contributor

negue commented Dec 19, 2011

Great!

True Fixed Toolbars works on Samsung Galaxy Tab (Android 2.2)

But the z-index of the Switch-Control is higher than the Toolbars.

@woutervanwijk

This comment has been minimized.

Show comment
Hide comment
@woutervanwijk

woutervanwijk Dec 19, 2011

This is much better on iOS5 iphone and pad! Great! Two (small) problems: same here with the z-index of the switch control, and when switching from landscape to portrait and back, the toolbars are only half visible. Except from that a much better user experience already.

woutervanwijk commented Dec 19, 2011

This is much better on iOS5 iphone and pad! Great! Two (small) problems: same here with the z-index of the switch control, and when switching from landscape to portrait and back, the toolbars are only half visible. Except from that a much better user experience already.

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 20, 2011

Contributor

I just updated the demo on our site with the latest version of the fixed toolbars from the css-fixed branch:
http://filamentgroup.com/tests/jqm-nativefixed/

Contributor

toddparker commented Dec 20, 2011

I just updated the demo on our site with the latest version of the fixed toolbars from the css-fixed branch:
http://filamentgroup.com/tests/jqm-nativefixed/

@woutervanwijk

This comment has been minimized.

Show comment
Hide comment
@woutervanwijk

woutervanwijk Dec 20, 2011

It works great on firefox and chrome (most recent non-beta versions), but only until I focus on one of the form-controls in the page. After that, the toolbars disappear suddenly and get out of position.

woutervanwijk commented Dec 20, 2011

It works great on firefox and chrome (most recent non-beta versions), but only until I focus on one of the form-controls in the page. After that, the toolbars disappear suddenly and get out of position.

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 21, 2011

Contributor

Yeah, we're still refining how to not hide the toolbars when interacting with widgets vs. tapping the page.

Contributor

toddparker commented Dec 21, 2011

Yeah, we're still refining how to not hide the toolbars when interacting with widgets vs. tapping the page.

@rbdcti

This comment has been minimized.

Show comment
Hide comment
@rbdcti

rbdcti Dec 24, 2011

Contributor

Hey guys, looking forward to true fixed toolbars under iOS 5, et al, however both the current css-fixed branch with my app and the demo at http://filamentgroup.com/tests/jqm-nativefixed/ (fixed toolbars page, obviously) do not gracefully degrade on my iPhone 4 running iOS 4.3.1. I am seeing the footer all the way down at the bottom of the page, not 'hovering' like the current JQM mainline behavior (i.e. you have to scroll all the way down to see it)...just wanted to make sure you know about this. I can provide more info/screenshots as necessary.

(I was going to go with the css-fixed branch and manually port over the fix from pull request #3050 for the degraded toolbar code, but I noticed all that logic was gone, as Todd said above.)

Contributor

rbdcti commented Dec 24, 2011

Hey guys, looking forward to true fixed toolbars under iOS 5, et al, however both the current css-fixed branch with my app and the demo at http://filamentgroup.com/tests/jqm-nativefixed/ (fixed toolbars page, obviously) do not gracefully degrade on my iPhone 4 running iOS 4.3.1. I am seeing the footer all the way down at the bottom of the page, not 'hovering' like the current JQM mainline behavior (i.e. you have to scroll all the way down to see it)...just wanted to make sure you know about this. I can provide more info/screenshots as necessary.

(I was going to go with the css-fixed branch and manually port over the fix from pull request #3050 for the degraded toolbar code, but I noticed all that logic was gone, as Todd said above.)

@scottjehl

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Dec 26, 2011

Contributor

Hey rbdrbd,
Thanks for the feedback. Actually, what you've described is the behavior we're aiming for, as iOS5's share is increasing steadily. Our aim is to try and support true fixed positioning, and let browsers that can't support it (like ios4) degrade to statically positioned toolbars at the top and bottom of the document, rather than the screen. Some browsers like ios4 get it halfway-right, or half-wrong really, so we're manually kicking them out to avoid usability issues.

The way the new plugin is written will make it easy to polyfill the support in devices like ios4 more easily, or at least to the level that we support it in master now, which uses fade-in and fade-out to hide during scroll.

Contributor

scottjehl commented Dec 26, 2011

Hey rbdrbd,
Thanks for the feedback. Actually, what you've described is the behavior we're aiming for, as iOS5's share is increasing steadily. Our aim is to try and support true fixed positioning, and let browsers that can't support it (like ios4) degrade to statically positioned toolbars at the top and bottom of the document, rather than the screen. Some browsers like ios4 get it halfway-right, or half-wrong really, so we're manually kicking them out to avoid usability issues.

The way the new plugin is written will make it easy to polyfill the support in devices like ios4 more easily, or at least to the level that we support it in master now, which uses fade-in and fade-out to hide during scroll.

@scottjehl

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Dec 26, 2011

Contributor

Hi Todd and everyone.
There are some updates in the CSS-Fixed branch that could use some device testing. Some known-misbehaving browsers are opted out now: iOS<5, Android Webkit < 2.2, Opera Mini, Fennec < 6, and WebOS < 3. Also, touch overflow support is back in again using the same API, though it's now part of core instead of being tied to the fixedtoolbars plugin. It's false by default and could use some iOS5 testing for odd behavior.

Today's commits https://github.com/jquery/jquery-mobile/commits/css-fixed

Thanks!

Contributor

scottjehl commented Dec 26, 2011

Hi Todd and everyone.
There are some updates in the CSS-Fixed branch that could use some device testing. Some known-misbehaving browsers are opted out now: iOS<5, Android Webkit < 2.2, Opera Mini, Fennec < 6, and WebOS < 3. Also, touch overflow support is back in again using the same API, though it's now part of core instead of being tied to the fixedtoolbars plugin. It's false by default and could use some iOS5 testing for odd behavior.

Today's commits https://github.com/jquery/jquery-mobile/commits/css-fixed

Thanks!

@rbdcti

This comment has been minimized.

Show comment
Hide comment
@rbdcti

rbdcti Dec 28, 2011

Contributor

scottjehl: Thanks for that great info. That makes sense. I notice you did say "let browsers that can't support it (like ios4) degrade to statically positioned toolbars at the top and bottom of the document, rather than the screen". Does this mean that even if my markup has only a persistent footer toolbar, when and if it's viewed on an iOS v4 (etc) type device, JQM will automatically add a statically positioned toolbar under the header bar that is the same as the statically positioned toolbar at the bottom of the document? So I'd get this behavior for free basically in that case?

I'm asking because I didn't see this automatic header behavior on the css-fixed build I tried. I did notice you made a number of updates a few days ago, so I can try again if you added this. Also, is there a page content length threshold that determines if this header is shown (e.g. don't show it if all the content fits on the display)?

P.S. - If we're degrading to statically positioned toolbars, I do like that behavior the best. It would be a major usability issue to not have the header, especially on very long pages.

Contributor

rbdcti commented Dec 28, 2011

scottjehl: Thanks for that great info. That makes sense. I notice you did say "let browsers that can't support it (like ios4) degrade to statically positioned toolbars at the top and bottom of the document, rather than the screen". Does this mean that even if my markup has only a persistent footer toolbar, when and if it's viewed on an iOS v4 (etc) type device, JQM will automatically add a statically positioned toolbar under the header bar that is the same as the statically positioned toolbar at the bottom of the document? So I'd get this behavior for free basically in that case?

I'm asking because I didn't see this automatic header behavior on the css-fixed build I tried. I did notice you made a number of updates a few days ago, so I can try again if you added this. Also, is there a page content length threshold that determines if this header is shown (e.g. don't show it if all the content fits on the display)?

P.S. - If we're degrading to statically positioned toolbars, I do like that behavior the best. It would be a major usability issue to not have the header, especially on very long pages.

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 29, 2011

Contributor

@rbdrbd - In browsers that don't support :fixed, the toolbars will just fall back to being in the document flow (static) so a header will be first, then the content, then the footer - all will scroll with the document. Imagine the page without the fixed data attribute. Think we're doing what you prefer :)

Contributor

toddparker commented Dec 29, 2011

@rbdrbd - In browsers that don't support :fixed, the toolbars will just fall back to being in the document flow (static) so a header will be first, then the content, then the footer - all will scroll with the document. Imagine the page without the fixed data attribute. Think we're doing what you prefer :)

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 30, 2011

Contributor

Test results with the latest "css-fixed" branch code. The tap to hide isn't quite working right now (hides, then shows right away & z-index incorrect after toggle) and we might want to add in a fallback to static is the height of the fixed toolbars are more than X% of the screen height to keep this from taking over a small screen device.

Android 2.1 - Now excluded from fixed: rules, toolbars now safely fall back static positioning
Android 2.3 - True fixed toolbars
Kindle Fire - True fixed toolbars
Honeycomb 3.0 - True fixed toolbars
iOS4 - Toolbars safely fall back static positioning
iOS5 - True fixed toolbars, tap to toggle works on the footer and both bars on the fullscreen page
BB7 - True fixed toolbars but the toolbars take up 40+% of the height of the Curve - is static better?
BB5/6 - Bars scroll with page and re-position after scroll stop but functional
WebOS 1.4 - Toolbars safely fall back to static positioning
Firefox Mobile 9 + 10 beta - Not true fixed, bars scroll with page and re-position after scroll stop but functional
Older Firefox mobile - falls back to static positioning (manually exclude older than version 6)
Opera Mini - Excluded, falls back to static positioning
Opera Mobile 11.5 - Bars scroll with page and re-position after scroll stop but functional
Dolphin 7.2.1 (Bada) - True fixed toolbars
UC Web - Toolbars safely fall back static positioning

Contributor

toddparker commented Dec 30, 2011

Test results with the latest "css-fixed" branch code. The tap to hide isn't quite working right now (hides, then shows right away & z-index incorrect after toggle) and we might want to add in a fallback to static is the height of the fixed toolbars are more than X% of the screen height to keep this from taking over a small screen device.

Android 2.1 - Now excluded from fixed: rules, toolbars now safely fall back static positioning
Android 2.3 - True fixed toolbars
Kindle Fire - True fixed toolbars
Honeycomb 3.0 - True fixed toolbars
iOS4 - Toolbars safely fall back static positioning
iOS5 - True fixed toolbars, tap to toggle works on the footer and both bars on the fullscreen page
BB7 - True fixed toolbars but the toolbars take up 40+% of the height of the Curve - is static better?
BB5/6 - Bars scroll with page and re-position after scroll stop but functional
WebOS 1.4 - Toolbars safely fall back to static positioning
Firefox Mobile 9 + 10 beta - Not true fixed, bars scroll with page and re-position after scroll stop but functional
Older Firefox mobile - falls back to static positioning (manually exclude older than version 6)
Opera Mini - Excluded, falls back to static positioning
Opera Mobile 11.5 - Bars scroll with page and re-position after scroll stop but functional
Dolphin 7.2.1 (Bada) - True fixed toolbars
UC Web - Toolbars safely fall back static positioning

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 30, 2011

Contributor

Please help us test on other browsers and report unique results here.

Contributor

toddparker commented Dec 30, 2011

Please help us test on other browsers and report unique results here.

@staabm

This comment has been minimized.

Show comment
Hide comment
@staabm

staabm Dec 30, 2011

Contributor

to help you testing different git branches than "master" it would be cool if all github branches would be synced with httü://jquerymobile.com/test (maybe a subfolder for each branch?).

Contributor

staabm commented Dec 30, 2011

to help you testing different git branches than "master" it would be cool if all github branches would be synced with httü://jquerymobile.com/test (maybe a subfolder for each branch?).

@lhwparis

This comment has been minimized.

Show comment
Hide comment
@lhwparis

lhwparis Dec 30, 2011

you are not testing windowsPhone 7.5? i thought its a jqm a-grade system?

lhwparis commented Dec 30, 2011

you are not testing windowsPhone 7.5? i thought its a jqm a-grade system?

@scottjehl

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Dec 30, 2011

Contributor

Windows phone will need testing, yes - both pre and post Mango :)

Contributor

scottjehl commented Dec 30, 2011

Windows phone will need testing, yes - both pre and post Mango :)

@scottjehl

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Dec 30, 2011

Contributor

Todd - great test results! Thanks.
I agree about opting out conditionally based on window or screen size - I
guess we'll also need to do that on resize and orientation change too...?
Always more complicated than it seems.. :)

For your note on iOS5 only toggling the footers - are you sure that wasn't
only when you were at the top of the page? The expected behavior for the
"fixed" (not fullscreen) toolbars is to only toggle a toolbar if it is
positioned away from its static resting place... otherwise you'll just see
it hide with blank space behind it. So if you are at the top of the page,
the expected behavior (at least in the way I built it so far) is for the
footer to hide, but the header to stay visible. The opposite would happen
when scrolled to the very bottom. Anywhere in between, both should toggle.

Can you confirm this is what you're seeing?

Contributor

scottjehl commented Dec 30, 2011

Todd - great test results! Thanks.
I agree about opting out conditionally based on window or screen size - I
guess we'll also need to do that on resize and orientation change too...?
Always more complicated than it seems.. :)

For your note on iOS5 only toggling the footers - are you sure that wasn't
only when you were at the top of the page? The expected behavior for the
"fixed" (not fullscreen) toolbars is to only toggle a toolbar if it is
positioned away from its static resting place... otherwise you'll just see
it hide with blank space behind it. So if you are at the top of the page,
the expected behavior (at least in the way I built it so far) is for the
footer to hide, but the header to stay visible. The opposite would happen
when scrolled to the very bottom. Anywhere in between, both should toggle.

Can you confirm this is what you're seeing?

@lhwparis

This comment has been minimized.

Show comment
Hide comment
@lhwparis

lhwparis Dec 30, 2011

why are you not skipping support for pre-mango? 100% of devices got the mango update and the mobile ie9 is a great step ahead. so why spend time to optimize jqm for very few users not updating there device for any reason?

lhwparis commented Dec 30, 2011

why are you not skipping support for pre-mango? 100% of devices got the mango update and the mobile ie9 is a great step ahead. so why spend time to optimize jqm for very few users not updating there device for any reason?

@scottjehl

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Dec 30, 2011

Contributor

Well, I think we should just test around and see how things fair is all.
Also, we still do support IE7 and up, which is essentially the same as
pre-mango. I want to make sure we aren't introducing any usability issues
mostly.

Contributor

scottjehl commented Dec 30, 2011

Well, I think we should just test around and see how things fair is all.
Also, we still do support IE7 and up, which is essentially the same as
pre-mango. I want to make sure we aren't introducing any usability issues
mostly.

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 30, 2011

Contributor

WP7 is A grade but now I wonder if we need A+ grade for things like fixed toolbar and overflow support. These are nice to have features that we layer on top of the A grade experience.

Contributor

toddparker commented Dec 30, 2011

WP7 is A grade but now I wonder if we need A+ grade for things like fixed toolbar and overflow support. These are nice to have features that we layer on top of the A grade experience.

@lhwparis

This comment has been minimized.

Show comment
Hide comment
@lhwparis

lhwparis Dec 30, 2011

Dont think A+ grade is needed. i think a-grad says: all features are working. so fixed toolbars should work in all a-grade browsers it does not matter they are fixed positioned or fixed by js-hack.

lhwparis commented Dec 30, 2011

Dont think A+ grade is needed. i think a-grad says: all features are working. so fixed toolbars should work in all a-grade browsers it does not matter they are fixed positioned or fixed by js-hack.

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 30, 2011

Contributor

@scottjehl Just re-tested and you're right on the hiding - it's working as expected. On opting out based on size, thinking this could just be a simple test on initial page create that just ensures that these don't make the page unusable. The scenario I'm thinking of is a fixed header and tall iOS style footer which would use the majority of the height on a bb curve.

@lhwparis I was sort of kidding by A+but there will be some features that will work even better than others within grade A. In the case of fixed toolbars, my thought right now is that we won't include the poly fill to dynamically reposition them by default because the result isn't that good and it takes quite a bit of code. I think it's a better experience to fall back to static toolbars that scroll with the page but we can look at how to offer the old poky fill behavior as an optional plugin if you really need that in iOS4.

Oh, and I wasn't thoroughly testing this in WP7/7.5 because early tests showed this simply rendered as static. Most of the effort has been to find misbehaving browsers and figure out how to exclude them.

Contributor

toddparker commented Dec 30, 2011

@scottjehl Just re-tested and you're right on the hiding - it's working as expected. On opting out based on size, thinking this could just be a simple test on initial page create that just ensures that these don't make the page unusable. The scenario I'm thinking of is a fixed header and tall iOS style footer which would use the majority of the height on a bb curve.

@lhwparis I was sort of kidding by A+but there will be some features that will work even better than others within grade A. In the case of fixed toolbars, my thought right now is that we won't include the poly fill to dynamically reposition them by default because the result isn't that good and it takes quite a bit of code. I think it's a better experience to fall back to static toolbars that scroll with the page but we can look at how to offer the old poky fill behavior as an optional plugin if you really need that in iOS4.

Oh, and I wasn't thoroughly testing this in WP7/7.5 because early tests showed this simply rendered as static. Most of the effort has been to find misbehaving browsers and figure out how to exclude them.

@agcolom

This comment has been minimized.

Show comment
Hide comment
@agcolom

agcolom Jan 25, 2012

Member

Hi Scott,

Thanks a lot for the clarification. This is exactly as I would expect it to work, so I am happy to see that we have the same view here... I've noticed that the file we are seeing is still not the "proper" latest version with all your changes, so will try again later...

best wishes,

Anne

Member

agcolom commented Jan 25, 2012

Hi Scott,

Thanks a lot for the clarification. This is exactly as I would expect it to work, so I am happy to see that we have the same view here... I've noticed that the file we are seeing is still not the "proper" latest version with all your changes, so will try again later...

best wishes,

Anne

@julianfuerderer

This comment has been minimized.

Show comment
Hide comment
@julianfuerderer

julianfuerderer Jan 26, 2012

Hello,

i have done many research via google to fix the problem.
I have a Samsung Galaxy S2 (Android 2.3.4), programming with Eclipse+jQueryMobile+Phonegap.

To describe the problem, i have also tried the Static-Footer-Bar example from
the official documentation:
Please visit

http://jquerymobile.com/test/docs/toolbars/footer-persist-c.html

The flow:

1. Coming to http://jquerymobile.com/test/docs/toolbars/footer-persist-c.html

2. After some clicking the links in the footer-bar the following happens:

I am on the page "Albums" and click on "Friends": Friends-Page not coming/loading and
Albums and Friends Links both stay in active-link state

Any Idea ?
Please help me...

julianfuerderer commented Jan 26, 2012

Hello,

i have done many research via google to fix the problem.
I have a Samsung Galaxy S2 (Android 2.3.4), programming with Eclipse+jQueryMobile+Phonegap.

To describe the problem, i have also tried the Static-Footer-Bar example from
the official documentation:
Please visit

http://jquerymobile.com/test/docs/toolbars/footer-persist-c.html

The flow:

1. Coming to http://jquerymobile.com/test/docs/toolbars/footer-persist-c.html

2. After some clicking the links in the footer-bar the following happens:

I am on the page "Albums" and click on "Friends": Friends-Page not coming/loading and
Albums and Friends Links both stay in active-link state

Any Idea ?
Please help me...

@agcolom

This comment has been minimized.

Show comment
Hide comment
@agcolom

agcolom Jan 26, 2012

Member

Hi Scott,

Looks like I am getting the correct file version now... can you let me know when you're ready for me to test (as I can see you are making changes now). I still see the issue with headers or footers not displayed when they should in some very specific cases. I can give you a full report this evening (in about 8h).

Anne

Member

agcolom commented Jan 26, 2012

Hi Scott,

Looks like I am getting the correct file version now... can you let me know when you're ready for me to test (as I can see you are making changes now). I still see the issue with headers or footers not displayed when they should in some very specific cases. I can give you a full report this evening (in about 8h).

Anne

@cjblomqvist

This comment has been minimized.

Show comment
Hide comment
@cjblomqvist

cjblomqvist Jan 26, 2012

@scottjehl: Update on Galaxy S2 -issue: I tried http://jquerymobile.com/test/docs/toolbars/footer-persist-c.html today and the issue with the true-fixed-positioned header/footer is gone. Now they follow the scrolling in a true persistent manner. Awesome work (as always)!

@julianfuerderer: I have seen this issue on multiple occasions on different elements in jQueryMobile, including the navbar, header, as well as the listview, and from testing I have a feeling that this problem happens when you manage to click after the page has loaded itself but before the browser is receptive to new (link-) clicks. Another guess would be that it happens when you do a touch that is too short - if I'm not incorrect the framework uses timers to decide whether to count it as a click or not? Regardless of the issue, I'd recommend using the stable 1.0 version instead of the latest development version until things have been properly sorted out.

cjblomqvist commented Jan 26, 2012

@scottjehl: Update on Galaxy S2 -issue: I tried http://jquerymobile.com/test/docs/toolbars/footer-persist-c.html today and the issue with the true-fixed-positioned header/footer is gone. Now they follow the scrolling in a true persistent manner. Awesome work (as always)!

@julianfuerderer: I have seen this issue on multiple occasions on different elements in jQueryMobile, including the navbar, header, as well as the listview, and from testing I have a feeling that this problem happens when you manage to click after the page has loaded itself but before the browser is receptive to new (link-) clicks. Another guess would be that it happens when you do a touch that is too short - if I'm not incorrect the framework uses timers to decide whether to count it as a click or not? Regardless of the issue, I'd recommend using the stable 1.0 version instead of the latest development version until things have been properly sorted out.

@dcarrith

This comment has been minimized.

Show comment
Hide comment
@dcarrith

dcarrith Jan 26, 2012

Contributor

@scottjehl: I just pulled down the latest and am seeing some great improvements. It seems like you've addressed everything that was reported yesterday. I have noticed a few issues that are a bit more esoteric and may just be caused by the way in which I've implemented something in my application. I haven't been able to reproduce them consistently though, so I'll report back on those later if I can identify something that might be related to the changes made for 3216.

There is one thing I've noticed that is probably related to the changes made for 3216. In my header, I have a back button and a home button. If I'm scrolled down in a page of Artists, for example, and I tap either of the buttons in the fixed header toolbar, it seems to usually register the tap event on the element below the fixed header toolbar. So, instead of going back, it selects whatever artist li element is under the toolbar. It doesn't seem to happen in Chrome on Windows 7, since I guess that isn't a tap event. It happens frequently on iOS5 and Android 2.3.7 stock browsers. If I very carefully do a kind of long tap (but not long enough to be a taphold) on the back button, I can most of the time get it to go back. But, it wasn't like that before these changes were made.

Contributor

dcarrith commented Jan 26, 2012

@scottjehl: I just pulled down the latest and am seeing some great improvements. It seems like you've addressed everything that was reported yesterday. I have noticed a few issues that are a bit more esoteric and may just be caused by the way in which I've implemented something in my application. I haven't been able to reproduce them consistently though, so I'll report back on those later if I can identify something that might be related to the changes made for 3216.

There is one thing I've noticed that is probably related to the changes made for 3216. In my header, I have a back button and a home button. If I'm scrolled down in a page of Artists, for example, and I tap either of the buttons in the fixed header toolbar, it seems to usually register the tap event on the element below the fixed header toolbar. So, instead of going back, it selects whatever artist li element is under the toolbar. It doesn't seem to happen in Chrome on Windows 7, since I guess that isn't a tap event. It happens frequently on iOS5 and Android 2.3.7 stock browsers. If I very carefully do a kind of long tap (but not long enough to be a taphold) on the back button, I can most of the time get it to go back. But, it wasn't like that before these changes were made.

@scottjehl

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Jan 26, 2012

Contributor

Hey Anne, and everyone else,

Please go forth and test away - I've got one item I'd still like to nail down on these (a list of tap targets that should be ignored for toggling toolbars, like anchors, form controls, etc).

Aside from that, the docs are updated now with all the new options and API details, as well as expected behavior.

Thanks again, you guys are all a huge help!

On Jan 26, 2012, at 6:57 PM, cjblomqvist wrote:

@scottjehl: Update on Galaxy S2 -issue: I tried http://jquerymobile.com/test/docs/toolbars/footer-persist-c.html today and the issue with the true-fixed-positioned header/footer is gone. Now they follow the scrolling in a true persistent manner. Awesome work (as always)!

@julianfuerderer: I have seen this issue on multiple occasions on different elements in jQueryMobile, including the navbar, header, as well as the listview, and from testing I have a feeling that this problem happens when you manage to click after the page has loaded itself but before the browser is receptive to new (link-) clicks. Another guess would be that it happens when you do a touch that is too short - if I'm not incorrect the framework uses timers to decide whether to count it as a click or not? Regardless of the issue, I'd recommend using the stable 1.0 version instead of the latest development version until things have been properly sorted out.


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

Contributor

scottjehl commented Jan 26, 2012

Hey Anne, and everyone else,

Please go forth and test away - I've got one item I'd still like to nail down on these (a list of tap targets that should be ignored for toggling toolbars, like anchors, form controls, etc).

Aside from that, the docs are updated now with all the new options and API details, as well as expected behavior.

Thanks again, you guys are all a huge help!

On Jan 26, 2012, at 6:57 PM, cjblomqvist wrote:

@scottjehl: Update on Galaxy S2 -issue: I tried http://jquerymobile.com/test/docs/toolbars/footer-persist-c.html today and the issue with the true-fixed-positioned header/footer is gone. Now they follow the scrolling in a true persistent manner. Awesome work (as always)!

@julianfuerderer: I have seen this issue on multiple occasions on different elements in jQueryMobile, including the navbar, header, as well as the listview, and from testing I have a feeling that this problem happens when you manage to click after the page has loaded itself but before the browser is receptive to new (link-) clicks. Another guess would be that it happens when you do a touch that is too short - if I'm not incorrect the framework uses timers to decide whether to count it as a click or not? Regardless of the issue, I'd recommend using the stable 1.0 version instead of the latest development version until things have been properly sorted out.


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

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker
Contributor

toddparker commented Jan 26, 2012

@agcolom

This comment has been minimized.

Show comment
Hide comment
@agcolom

agcolom Jan 26, 2012

Member

Todd, your link redirects to http://code.jquery.com/mobile/latest/demos/docs/toolbars/bars-fixed.html and the jquery.mobile.css does not seem to be the latest one (z-index is there for .fade.in and fade.out), but this morning (about 7h ago) this was different (z-indexes were not there).

It seems this is reading http://code.jquery.com/mobile/latest/demos/css/themes/default/jquery.mobile.css which does not seem updated??

Member

agcolom commented Jan 26, 2012

Todd, your link redirects to http://code.jquery.com/mobile/latest/demos/docs/toolbars/bars-fixed.html and the jquery.mobile.css does not seem to be the latest one (z-index is there for .fade.in and fade.out), but this morning (about 7h ago) this was different (z-indexes were not there).

It seems this is reading http://code.jquery.com/mobile/latest/demos/css/themes/default/jquery.mobile.css which does not seem updated??

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Jan 26, 2012

Contributor

Yeah, we're having lots of issues with the redirects. /test/ was working for me but if you get redirected, that other URL is out of date. Working on it.

Contributor

toddparker commented Jan 26, 2012

Yeah, we're having lots of issues with the redirects. /test/ was working for me but if you get redirected, that other URL is out of date. Working on it.

@agcolom

This comment has been minimized.

Show comment
Hide comment
@agcolom

agcolom Jan 26, 2012

Member

Todd, Scott,

the redirect issue seems to be related to which computer I use! All works fine with my new MacBook Air running Lion with FF9 and Safari 5.1.1 (and the transitions on the fixed headers and footers are absolutely gorgeous!!!!)

With my MacBook Pro running Snow Leopard, I get the redirect with FF8 and now it's all fine with Safari 5.1.1 there as well... I wonder whether this could be a cache issue on FF8. I'll try to clear the cache...

Member

agcolom commented Jan 26, 2012

Todd, Scott,

the redirect issue seems to be related to which computer I use! All works fine with my new MacBook Air running Lion with FF9 and Safari 5.1.1 (and the transitions on the fixed headers and footers are absolutely gorgeous!!!!)

With my MacBook Pro running Snow Leopard, I get the redirect with FF8 and now it's all fine with Safari 5.1.1 there as well... I wonder whether this could be a cache issue on FF8. I'll try to clear the cache...

@agcolom

This comment has been minimized.

Show comment
Hide comment
@agcolom

agcolom Jan 26, 2012

Member

OMG!!! I have cleared the cache and do not get the incorrect redirect anymore!!!
So if anyone else reports incorrect redirect, the solution could simply be to clear the cache!!! Sorry for causing you so much extra work!!!

Member

agcolom commented Jan 26, 2012

OMG!!! I have cleared the cache and do not get the incorrect redirect anymore!!!
So if anyone else reports incorrect redirect, the solution could simply be to clear the cache!!! Sorry for causing you so much extra work!!!

@agcolom

This comment has been minimized.

Show comment
Hide comment
@agcolom

agcolom Jan 26, 2012

Member

Hi Scott,

Tiny minor things when testing http://jquerymobile.com/test/docs/toolbars/bars-fixed.html

in FF8.0.1 and FF9, when at the bottom of the page there is something like a 1px difference between the fixed footer and the normal footer (play with position: abolute (remove it and bring it back) in your element inspector, you'll notice the difference)...

.ui-fixed-hidden {
    position: absolute;
 }

But I think this is a problem with the browser itself, as there are other cases of JQM elements with the same minor pb...

In Safari 5.1.1, if you toggle while at the top of the page or at the bottom, no problem at all. However, if you toggle while in the middle of the page (anywhere really but so that you cannot see the non-fixed header and footer) and toggle to display the bars, the text in the header and footer looks a bit bolder. if you then move to the bottom of the page and toggle again, you'll see the difference in the display of the text in the footer: bolder when fixed positioning is shown, and not bold when normal footer is shown. If you do the same with the header, i.e. go to the middle of the page and toggle to display fixed bars. now go to the top of the page, and toggle again. The header remains bold. Now, go again to the middle of the page, toggle to show fixed bars, look carefully at the bold looking header, toggle to make it disappear from the current view and scroll to the top. Look at the header text, it is not bold anymore. If you toggle from here the header and footer will be displayed without the bold look...

I have not managed to put my finger on what is causing this... really quite minor... and the transitions look amazing!!!

Anne

Member

agcolom commented Jan 26, 2012

Hi Scott,

Tiny minor things when testing http://jquerymobile.com/test/docs/toolbars/bars-fixed.html

in FF8.0.1 and FF9, when at the bottom of the page there is something like a 1px difference between the fixed footer and the normal footer (play with position: abolute (remove it and bring it back) in your element inspector, you'll notice the difference)...

.ui-fixed-hidden {
    position: absolute;
 }

But I think this is a problem with the browser itself, as there are other cases of JQM elements with the same minor pb...

In Safari 5.1.1, if you toggle while at the top of the page or at the bottom, no problem at all. However, if you toggle while in the middle of the page (anywhere really but so that you cannot see the non-fixed header and footer) and toggle to display the bars, the text in the header and footer looks a bit bolder. if you then move to the bottom of the page and toggle again, you'll see the difference in the display of the text in the footer: bolder when fixed positioning is shown, and not bold when normal footer is shown. If you do the same with the header, i.e. go to the middle of the page and toggle to display fixed bars. now go to the top of the page, and toggle again. The header remains bold. Now, go again to the middle of the page, toggle to show fixed bars, look carefully at the bold looking header, toggle to make it disappear from the current view and scroll to the top. Look at the header text, it is not bold anymore. If you toggle from here the header and footer will be displayed without the bold look...

I have not managed to put my finger on what is causing this... really quite minor... and the transitions look amazing!!!

Anne

@brunnsbe

This comment has been minimized.

Show comment
Hide comment
@brunnsbe

brunnsbe Feb 2, 2012

I made some new testing using http://jquerymobile.com/test/docs/toolbars/bars-fixed.html on Nokia N9 (Meego 1.2, built-in browser, release PR 1.1) and it still doesn't work.

  • The fixed footer isn't fixed at the bottom, its position is fixed and doesn't scroll with the rest of the document.
  • The fixed header is only shown at the top of the document
  • Clicking on the document toggles the visibility of the footer but in quite an ugly way, it blinks a few times.

brunnsbe commented Feb 2, 2012

I made some new testing using http://jquerymobile.com/test/docs/toolbars/bars-fixed.html on Nokia N9 (Meego 1.2, built-in browser, release PR 1.1) and it still doesn't work.

  • The fixed footer isn't fixed at the bottom, its position is fixed and doesn't scroll with the rest of the document.
  • The fixed header is only shown at the top of the document
  • Clicking on the document toggles the visibility of the footer but in quite an ugly way, it blinks a few times.
@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Feb 2, 2012

Contributor

@brunnsbe - Thanks, I just re-tested on my N9 and the browser has a broken :fixed implementation so we need to forcefully degrade this to static positioning by blacklisting it. It amazes me how many mobile browsers shipped with a completely broken fixed feature.

Contributor

toddparker commented Feb 2, 2012

@brunnsbe - Thanks, I just re-tested on my N9 and the browser has a broken :fixed implementation so we need to forcefully degrade this to static positioning by blacklisting it. It amazes me how many mobile browsers shipped with a completely broken fixed feature.

@brunnsbe

This comment has been minimized.

Show comment
Hide comment
@brunnsbe

brunnsbe Feb 3, 2012

Yes, it's quite annoying with the broken implementations. :-(
The N9 will get a new firmware in the end of this month (PR 1.2), I read somewhere that the new firmware also contains upgrades to the internal browser. Hopefully the broken :fixed implementation has been fixed in that release.

Edit (28.2.2012): I have now tested the PR 1.2 release and the :fixed implementation is still broken.

brunnsbe commented Feb 3, 2012

Yes, it's quite annoying with the broken implementations. :-(
The N9 will get a new firmware in the end of this month (PR 1.2), I read somewhere that the new firmware also contains upgrades to the internal browser. Hopefully the broken :fixed implementation has been fixed in that release.

Edit (28.2.2012): I have now tested the PR 1.2 release and the :fixed implementation is still broken.

@scottjehl

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Feb 3, 2012

Contributor

Just an update: n9 should be opted out now, and the toolbars should toggle properly in Android.

On Feb 3, 2012, at 5:28 PM, brunnsbe wrote:

Yes, it's quite annoying with the broken implementations. :-(
The N9 will get a new firmware in the end of this month (PR 1.2), I read somewhere that the new firmware also contains upgrades to the internal browser. Hopefully the broken :fixed implementation has been fixed in that release.


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

Contributor

scottjehl commented Feb 3, 2012

Just an update: n9 should be opted out now, and the toolbars should toggle properly in Android.

On Feb 3, 2012, at 5:28 PM, brunnsbe wrote:

Yes, it's quite annoying with the broken implementations. :-(
The N9 will get a new firmware in the end of this month (PR 1.2), I read somewhere that the new firmware also contains upgrades to the internal browser. Hopefully the broken :fixed implementation has been fixed in that release.


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

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Feb 3, 2012

Contributor

Our N9 is now falling back to static positioning on toolbars in master.

Contributor

toddparker commented Feb 3, 2012

Our N9 is now falling back to static positioning on toolbars in master.

@JasonBSteele

This comment has been minimized.

Show comment
Hide comment
@JasonBSteele

JasonBSteele Feb 5, 2012

When I test http://jquerymobile.com/branches/css-fixed/docs/toolbars/bars-fixed.html on a Galaxy Nexus with Android 4.0.2 I get the following behaviour:
The toolbars are solidly fixed and scrolling is smooth
However if I tap the screen the toolbars disappear and then very quickly reappear.
Also if the inset list on this page happens to be under a toolbar, when the toolbar reappears it is behind the list.

IMHO I tend to agree with a previous comment on whether the touch toggle should be the default behaviour or included at all if it causes problems.

JasonBSteele commented Feb 5, 2012

When I test http://jquerymobile.com/branches/css-fixed/docs/toolbars/bars-fixed.html on a Galaxy Nexus with Android 4.0.2 I get the following behaviour:
The toolbars are solidly fixed and scrolling is smooth
However if I tap the screen the toolbars disappear and then very quickly reappear.
Also if the inset list on this page happens to be under a toolbar, when the toolbar reappears it is behind the list.

IMHO I tend to agree with a previous comment on whether the touch toggle should be the default behaviour or included at all if it causes problems.

@scottjehl

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Feb 6, 2012

Contributor

Hi @JasonBSteele - just a note, that's an old url. If you can, test on latest master, as that's where we've been working on this feature for the last few weeks.

Contributor

scottjehl commented Feb 6, 2012

Hi @JasonBSteele - just a note, that's an old url. If you can, test on latest master, as that's where we've been working on this feature for the last few weeks.

scottjehl pushed a commit that referenced this issue Feb 6, 2012

scottjehl
Addresses issues with #3216, where fixed toolbars could not be toggle…
…d on Android, or if toggle-able, they would scroll with the page at load, only working after toggling their appearance manually. With this change in place, scaling properly disables on Android 2.3 when fixed toolbars are in play (an apparent requirement for fixed positioning to work on that platform), while ensuring zoom can be restored after visiting a page that does not have fixed toolbars, at least on iOS.
@scottjehl

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Feb 6, 2012

Contributor

Okay, folks, I think we're probably in as good of shape as we're going to get with this one. Support is looking great on a boatload of devices, and falls back respectably in most others we've tested.

My latest commit allows for toggling in Android while ensuring fixed toolbars still stay fixed at pageload, on most Android 2.3 devices, such as the emulator, and I'm assuming many other popular devices.

@toddparker with your testing confirmation, I'd like to declare this one ready. Here's some additional detail of what I found today:

There are some edge cases to fixed support, even within OSs that are supposed to work: I've found at least 2 stock Android 2.3 devices (HTC devices with Sense UI, and Samsung Galaxy Mini) have webkit ports that do not allow user scaling to be disabled at all through any apparent means. While this is generally a good thing for users, it means position: fixed doesn't work in those places either, since zoom must be disabled on 2.3 for that to work. In these platforms, you'll get scrollbars that scroll with the page content and reposition after scroll. Opting them out of fixed will mean slicing our UA detection even further to target specific carrier implementations of 2.3... the need for a solid feature test is getting even more important!

I found that you can actually get position:fixed to work on 2.3 without disabling user scaling if you apply a 3D transform to the fixed elements. However, that transform prevents the elements from being toggled to other positioning models, like absolute, which is a feature we need for supporting our toggling. Not helpful for us, but maybe for others. Here's a sample page with zoom enabled that works on 2.3: http://jsbin.com/izakek

In the commit above, I noticed that zoom wasn't properly being disabled on common Android 2.3 devices with our $.mobile.zoom utility, and adding user-scalable=no to our existing maximum-scale=1 disabling value seemed to fix that without disabling zoom for good on iOS...

Anyway, it's clear that there are some implementations out there that this may cause some issues in. We'll have to watch it closely, and if anyone has ideas for a new approach to feature testing fixed (that doesn't introduce false results on some platforms), we are so interested :)

Contributor

scottjehl commented Feb 6, 2012

Okay, folks, I think we're probably in as good of shape as we're going to get with this one. Support is looking great on a boatload of devices, and falls back respectably in most others we've tested.

My latest commit allows for toggling in Android while ensuring fixed toolbars still stay fixed at pageload, on most Android 2.3 devices, such as the emulator, and I'm assuming many other popular devices.

@toddparker with your testing confirmation, I'd like to declare this one ready. Here's some additional detail of what I found today:

There are some edge cases to fixed support, even within OSs that are supposed to work: I've found at least 2 stock Android 2.3 devices (HTC devices with Sense UI, and Samsung Galaxy Mini) have webkit ports that do not allow user scaling to be disabled at all through any apparent means. While this is generally a good thing for users, it means position: fixed doesn't work in those places either, since zoom must be disabled on 2.3 for that to work. In these platforms, you'll get scrollbars that scroll with the page content and reposition after scroll. Opting them out of fixed will mean slicing our UA detection even further to target specific carrier implementations of 2.3... the need for a solid feature test is getting even more important!

I found that you can actually get position:fixed to work on 2.3 without disabling user scaling if you apply a 3D transform to the fixed elements. However, that transform prevents the elements from being toggled to other positioning models, like absolute, which is a feature we need for supporting our toggling. Not helpful for us, but maybe for others. Here's a sample page with zoom enabled that works on 2.3: http://jsbin.com/izakek

In the commit above, I noticed that zoom wasn't properly being disabled on common Android 2.3 devices with our $.mobile.zoom utility, and adding user-scalable=no to our existing maximum-scale=1 disabling value seemed to fix that without disabling zoom for good on iOS...

Anyway, it's clear that there are some implementations out there that this may cause some issues in. We'll have to watch it closely, and if anyone has ideas for a new approach to feature testing fixed (that doesn't introduce false results on some platforms), we are so interested :)

@scottjehl

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Feb 6, 2012

Contributor

Oh, lastly, please test Master or the following URL, which should be up-to-date now:

http://jquerymobile.com/test/docs/toolbars/bars-fixed.html

Contributor

scottjehl commented Feb 6, 2012

Oh, lastly, please test Master or the following URL, which should be up-to-date now:

http://jquerymobile.com/test/docs/toolbars/bars-fixed.html

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Feb 6, 2012

Contributor

Works great on both our Android 2.3 devices and our 2.2 phone. I think that if an OEM has monkeyed with the browser settings, there isn't too much we can do really. Not hiding the fixed toolbars when the keyboard opens would be usability disaster, especially on short screens or landscape mode so if we need to pick our poison here, I'd go with the more standard approach that preserves the toggle behavior. We should document this tradeoff int eh docs how to turn of the toggle behavior and where to apply that transform so if someone is building a native app and they are careful, they can go the other way.

One small thing we might want to consider adding: If you're focused in an input (toolbars are hidden) and immediately tap on another input, the toolbars briefly show then hide. Wonder if we can keep them hidden if you blur but focus back within a brief time window.

Contributor

toddparker commented Feb 6, 2012

Works great on both our Android 2.3 devices and our 2.2 phone. I think that if an OEM has monkeyed with the browser settings, there isn't too much we can do really. Not hiding the fixed toolbars when the keyboard opens would be usability disaster, especially on short screens or landscape mode so if we need to pick our poison here, I'd go with the more standard approach that preserves the toggle behavior. We should document this tradeoff int eh docs how to turn of the toggle behavior and where to apply that transform so if someone is building a native app and they are careful, they can go the other way.

One small thing we might want to consider adding: If you're focused in an input (toolbars are hidden) and immediately tap on another input, the toolbars briefly show then hide. Wonder if we can keep them hidden if you blur but focus back within a brief time window.

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Feb 6, 2012

Contributor

The last thing we need to do is make some test pages with more form elements inside fixed toolbars to see how everything works. @Wilto is working on finishing up the elements so we can do that soon. We should have a bunch of demo pages showing how these work.

Oh, and here's another critical reason for not adding the transform: People were reporting that the home button wasn't clickable if you scrolled down a bit with the transform in place. Just another Android bug, but a huge usability issue.

Contributor

toddparker commented Feb 6, 2012

The last thing we need to do is make some test pages with more form elements inside fixed toolbars to see how everything works. @Wilto is working on finishing up the elements so we can do that soon. We should have a bunch of demo pages showing how these work.

Oh, and here's another critical reason for not adding the transform: People were reporting that the home button wasn't clickable if you scrolled down a bit with the transform in place. Just another Android bug, but a huge usability issue.

@ricky-f

This comment has been minimized.

Show comment
Hide comment
@ricky-f

ricky-f Feb 8, 2012

Hi Guys,

Great job on this so far. I’ve been testing on iOS 5.0.1 and have discovered an issue. When using fixed toolbars with clickable form elements in them. After you call $.mobile.silentScroll(), the toolbar visually remains in place but the form elements are no longer clickable. It appears that the ‘click’ area does not reposition properly. Performing a manual scroll seems to set this right again.

I’ve put together a little demo here http://www.philliphaydon.com/scrolldemo/ Source is here https://gist.github.com/1763662 to demonstrate the issue. This appears to only be an issue on iOS 5.0.1 so you will need to run it on an iOS5 device to reproduce the issue. Click on the ‘PAGE DOWN’ button in the footer toolbar once, the page will scroll. Then try click on it again and you won’t be able to. If you then manually scroll it resets and you will be able to click the button again and reproduce the issue again. This also happens for form elements in the header. E..g in the example, click page down and then try click the home button which won’t do anything.

If you want to visually see where the clickable area is repositioning to, you can turn tapToggle to true then click the ‘PAGE DOWN’ button, the page will scroll, click it again and then the toolbars will hide and then click a third time where the ‘hidden’ button should be and the toolbar will appear towards the top of the page. This is where the clickable area has gone. Let me know if you have any questions.

Thanks,
Ricky

ricky-f commented Feb 8, 2012

Hi Guys,

Great job on this so far. I’ve been testing on iOS 5.0.1 and have discovered an issue. When using fixed toolbars with clickable form elements in them. After you call $.mobile.silentScroll(), the toolbar visually remains in place but the form elements are no longer clickable. It appears that the ‘click’ area does not reposition properly. Performing a manual scroll seems to set this right again.

I’ve put together a little demo here http://www.philliphaydon.com/scrolldemo/ Source is here https://gist.github.com/1763662 to demonstrate the issue. This appears to only be an issue on iOS 5.0.1 so you will need to run it on an iOS5 device to reproduce the issue. Click on the ‘PAGE DOWN’ button in the footer toolbar once, the page will scroll. Then try click on it again and you won’t be able to. If you then manually scroll it resets and you will be able to click the button again and reproduce the issue again. This also happens for form elements in the header. E..g in the example, click page down and then try click the home button which won’t do anything.

If you want to visually see where the clickable area is repositioning to, you can turn tapToggle to true then click the ‘PAGE DOWN’ button, the page will scroll, click it again and then the toolbars will hide and then click a third time where the ‘hidden’ button should be and the toolbar will appear towards the top of the page. This is where the clickable area has gone. Let me know if you have any questions.

Thanks,
Ricky

@hallatore

This comment has been minimized.

Show comment
Hide comment
@hallatore

hallatore Feb 8, 2012

http://jquerymobile.com/test/docs/toolbars/bars-fixed.html
This one doesn't do anything on wp7. header and footer are both static.

hallatore commented Feb 8, 2012

http://jquerymobile.com/test/docs/toolbars/bars-fixed.html
This one doesn't do anything on wp7. header and footer are both static.

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Feb 8, 2012

Contributor

@hallatore That's right. The new fixed toolbars in 1.1 rely on a browser supporting position:fixed. If this isn't supported, the toolbars will simply scroll with the document. The older technique where we dynamically re-position the bars after scroll won't be supported in 1.1 because this technique adds a fair amount of code weight and isn't super reliable (bars scroll with the page, etc.).

Contributor

toddparker commented Feb 8, 2012

@hallatore That's right. The new fixed toolbars in 1.1 rely on a browser supporting position:fixed. If this isn't supported, the toolbars will simply scroll with the document. The older technique where we dynamically re-position the bars after scroll won't be supported in 1.1 because this technique adds a fair amount of code weight and isn't super reliable (bars scroll with the page, etc.).

@ssssssssssss

This comment has been minimized.

Show comment
Hide comment
@ssssssssssss

ssssssssssss Feb 16, 2012

Just filed a bug about the position:fixed implementation in ICS 4.0.2 stock browser.
http://code.google.com/p/android/issues/detail?id=25610
Does anyone hit the same issue? Currently, I doesn't find a way to workaround.

ssssssssssss commented Feb 16, 2012

Just filed a bug about the position:fixed implementation in ICS 4.0.2 stock browser.
http://code.google.com/p/android/issues/detail?id=25610
Does anyone hit the same issue? Currently, I doesn't find a way to workaround.

@cjblomqvist

This comment has been minimized.

Show comment
Hide comment
@cjblomqvist

cjblomqvist Feb 16, 2012

sssssssssss: Yepp, I hit the same issue (also ICS 4.0.2 stock browser).

cjblomqvist commented Feb 16, 2012

sssssssssss: Yepp, I hit the same issue (also ICS 4.0.2 stock browser).

@barbalex

This comment has been minimized.

Show comment
Hide comment
@barbalex

barbalex Feb 16, 2012

Es, Same here
Am 16.02.2012 14:20 schrieb "cjblomqvist" <
reply@reply.github.com

:

sssssssssss: Yepp, I hit the same issue (also ICS 4.0.2 stock browser).


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

barbalex commented Feb 16, 2012

Es, Same here
Am 16.02.2012 14:20 schrieb "cjblomqvist" <
reply@reply.github.com

:

sssssssssss: Yepp, I hit the same issue (also ICS 4.0.2 stock browser).


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

@barbalex

This comment has been minimized.

Show comment
Hide comment
@barbalex

barbalex Feb 16, 2012

Es was to mean yes
Am 16.02.2012 17:21 schrieb "Alexander Gabriel" <
alexander.gabriel@bluewin.ch>:

Es, Same here
Am 16.02.2012 14:20 schrieb "cjblomqvist" <
reply@reply.github.com

:

sssssssssss: Yepp, I hit the same issue (also ICS 4.0.2 stock browser).


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

barbalex commented Feb 16, 2012

Es was to mean yes
Am 16.02.2012 17:21 schrieb "Alexander Gabriel" <
alexander.gabriel@bluewin.ch>:

Es, Same here
Am 16.02.2012 14:20 schrieb "cjblomqvist" <
reply@reply.github.com

:

sssssssssss: Yepp, I hit the same issue (also ICS 4.0.2 stock browser).


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

@phillip-haydon

This comment has been minimized.

Show comment
Hide comment
@phillip-haydon

phillip-haydon Feb 20, 2012

Is anyone able to answer this question?

#3216 (comment)

phillip-haydon commented Feb 20, 2012

Is anyone able to answer this question?

#3216 (comment)

@scottjehl

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Feb 20, 2012

Contributor

@phillip-haydon and @ricky-f :

ugh, sorry. I spent a long time responding to this one and now I don't see my message in the thread. The form must have never submitted.

I did a bunch of testing on this and found that this bug is indeed present in iOS5, and it has nothing to do with jQuery or jQuery Mobile. Here's a framework-free example that reproduces the bug.

http://jsbin.com/iredok

source:
http://jsbin.com/iredok/edit

For anyone programmatically scrolling a page that has form elements in a fixed footer, this bug is going to be a major problem. It doesn't appear to affect default use cases of jQM, even though we do programmatically scroll to remembered locations when returning to a page. I think it's because we do it before the page is is visible. Not sure though.

I don't think this should be a blocker for our feature, but we should probably make a note of it somewhere in the docs.

I wasn't able to find any workarounds. Let us know if you do.

I'll file a bug with Apple - maybe it'll be fixed in a future release :(

Contributor

scottjehl commented Feb 20, 2012

@phillip-haydon and @ricky-f :

ugh, sorry. I spent a long time responding to this one and now I don't see my message in the thread. The form must have never submitted.

I did a bunch of testing on this and found that this bug is indeed present in iOS5, and it has nothing to do with jQuery or jQuery Mobile. Here's a framework-free example that reproduces the bug.

http://jsbin.com/iredok

source:
http://jsbin.com/iredok/edit

For anyone programmatically scrolling a page that has form elements in a fixed footer, this bug is going to be a major problem. It doesn't appear to affect default use cases of jQM, even though we do programmatically scroll to remembered locations when returning to a page. I think it's because we do it before the page is is visible. Not sure though.

I don't think this should be a blocker for our feature, but we should probably make a note of it somewhere in the docs.

I wasn't able to find any workarounds. Let us know if you do.

I'll file a bug with Apple - maybe it'll be fixed in a future release :(

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Feb 22, 2012

Contributor

Hi all - I'm going to close this issue as fixed now that the new fixed toolbars have landed in master. Please help us test these this week so we can shake out any issues. Log as new issues please.

Contributor

toddparker commented Feb 22, 2012

Hi all - I'm going to close this issue as fixed now that the new fixed toolbars have landed in master. Please help us test these this week so we can shake out any issues. Log as new issues please.

@toddparker toddparker closed this Feb 22, 2012

@scottjehl

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Feb 22, 2012

Contributor

Woo! Thank you all for all the testing and feedback during development.

On Feb 22, 2012, at 10:05 AM, Todd Parker wrote:

Hi all - I'm going to close this issue as fixed now that the new fixed toolbars have landed in master. Please help us test these this week so we can shake out any issues. Log as new issues please.


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

Contributor

scottjehl commented Feb 22, 2012

Woo! Thank you all for all the testing and feedback during development.

On Feb 22, 2012, at 10:05 AM, Todd Parker wrote:

Hi all - I'm going to close this issue as fixed now that the new fixed toolbars have landed in master. Please help us test these this week so we can shake out any issues. Log as new issues please.


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

@abhipanda

This comment has been minimized.

Show comment
Hide comment
@abhipanda

abhipanda Feb 27, 2012

Thanks a lot for this stupendous effort.

abhipanda commented Feb 27, 2012

Thanks a lot for this stupendous effort.

@rauanmayemir

This comment has been minimized.

Show comment
Hide comment
@rauanmayemir

rauanmayemir Apr 25, 2012

I have issue with fixed toolbars on small screens (320x480).
To reproduce, try to open initial link in android emulator for stated resolution: http://jquerymobile.com/demos/1.1.0-rc.2/docs/toolbars/bars-fixed.html

rauanmayemir commented Apr 25, 2012

I have issue with fixed toolbars on small screens (320x480).
To reproduce, try to open initial link in android emulator for stated resolution: http://jquerymobile.com/demos/1.1.0-rc.2/docs/toolbars/bars-fixed.html

@balshamali

This comment has been minimized.

Show comment
Hide comment
@balshamali

balshamali Apr 30, 2012

Ive been using the fixed toolbar lately and its great, in most scenarios. However, there is a bug that Ive spent two days trying to get a workaround for but haven't succeeded yet, so any help would be grateful! The testing was done on ios 5 iphone emulator and does not happen by testing in chrome. The fixed toolbar is not quite fixed when navigating between pages using a navbar in the footer. The fixed toolbar changes position if you are on one page, click on the top of the screen to auto-scroll to the top of safari and show the address bar, navigate to another page that is not full (as in occupy only half of the page with listview or something). The footer will rise from the bottom. It can be set back by scrolling. I tried to trigger a scroll event every time I switch pages but that doesn't seem to fix the issue. Please help!

balshamali commented Apr 30, 2012

Ive been using the fixed toolbar lately and its great, in most scenarios. However, there is a bug that Ive spent two days trying to get a workaround for but haven't succeeded yet, so any help would be grateful! The testing was done on ios 5 iphone emulator and does not happen by testing in chrome. The fixed toolbar is not quite fixed when navigating between pages using a navbar in the footer. The fixed toolbar changes position if you are on one page, click on the top of the screen to auto-scroll to the top of safari and show the address bar, navigate to another page that is not full (as in occupy only half of the page with listview or something). The footer will rise from the bottom. It can be set back by scrolling. I tried to trigger a scroll event every time I switch pages but that doesn't seem to fix the issue. Please help!

@jaspermdegroot

This comment has been minimized.

Show comment
Hide comment
@jaspermdegroot

jaspermdegroot Apr 30, 2012

Member

@rauanmaemirov @balshamali This issue is closed 2 months ago with a comment to open a new issue to report problems with fixed toolbars.

Member

jaspermdegroot commented Apr 30, 2012

@rauanmaemirov @balshamali This issue is closed 2 months ago with a comment to open a new issue to report problems with fixed toolbars.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment