Problems when switching height of sticky header

[neilpowers]

Hi,

Thanks for a great plugin!

I have implemented a sticky header based on the demo that is provided with one change which is causing problems in certain scenarios.

My change is that the header has a large height set in css before the .sticky class is attached.

Once .sticky class is attached a .sticky specific rule changes the height of the header.

This works fine in most scenarios. However, when the height of the page is only just scrollable the page jumps back to full height header element and wont display the minimized .sticky height of the header. The problem is not present when the page has a lot of content.

I have made the ammends to a local version of the sticky demo just to make sure it was not anything in my implementation.

Here is the demo i made to show the problem http://postnatalcounselling.com/original-waypoints-sticky-demo/ .

Any help you can suggest would be great. many thanks Neil

[imakewebthings]

However, when the height of the page is only just scrollable the page jumps back to full height header element and wont display the minimized .sticky height of the header. The problem is not present when the page has a lot of content.

Sorry, but I don't understand the issue or can't see it in the example. I see the increased height non-sticky header, and the shorter sticky state, but scrolling up and down at various window heights I don't see anything out of the ordinary. It may help if you phrase it in the following format.

• Action taken: (Specific steps on how to reproduce the problem)
• Expected results:
• Actual results:

[neilpowers]

Hi Caleb,

Thanks for looking at this. I will try to be clearer.

Action taken:
Using chrome or firefox, as issue doesn't occur in IE versions greater than 7, maximise the window so that the scroll bar has similar height to scroll as the actual height of the large header. I noticed that if window is not maximised the problem does not occur.

Then try to scroll.

Expected results:
The small height sticky header appears when scroll you down and is replaced with full height when sticky class is removed when you scroll up.

Actual results:
The small version of the header briefly appears before the full height header springs back into the original position

many thanks
Neil

[imakewebthings]

Crazy question, but is your page zoomed by chance? If you hit Ctrl/Cmd+0 (zero) does this still occur? I can't reproduce this in Windows or OSX Lion in either of the browsers you mentioned, except when text is in a zoomed out state.

[neilpowers]

No question is crazy when it comes to browser quirks :)

Zoom is reset and issue is still occurring both to me and a colleague who are both on Windows 7.

I can email you a screenshot as i can't see an option to add one in the github comments

cheers
Neil

[neilpowers]

Screen cast http://goo.gl/BJaOM

[imakewebthings]

Interesting, thanks for the video. I'll try reproducing on a Win 7 box tomorrow and get back to you on this.

[imakewebthings]

In the meantime, could try making #main-nav-holder's height equal to the large nav height (150px) instead of the commented out 30px, and tell me if this still occurs? Besides the advantage of having the content not shift when you switch states, the move to sticky state means it inherits a 0 height since it's only child is fixed. I suspect this is shifting the contents of the page and with it the current scroll offset of the page, instantly putting you back 'above' the waypoint scroll offset.

[neilpowers]

Thanks for the help. I will try this

[neilpowers]

Thanks Caleb, this has partially solved the issue and may well suit my purposes. However, i can see some circumstances where you will not want #main-nav-holder to have a fixed height. When the states switch , to the sticky header, the following content is in the same position it was before the switch, leaving excess blank space between the sticky header and this content until you scroll down further.

[imakewebthings]

So I finally understand the exact situation that will cause this. Your example is too tall for my 13" MBP running at 1280x800. So that I do not forget, here is the scenario:

1. You are very near the bottom of the page. Let's say for this scenario we are 900px from the top of the page and 50px away from the bottom. Between your current position and the bottom of the page you will trigger a waypoint.
2. You scroll down to trigger that waypoint. Something in the callback shortens the layout of the page, let's say by 150px. The change in height will keep your current scroll position the same and effectively subtract from your bottom distance, but only for the first 50px the remaining 100px in height change you are forced to "scroll up" such that you are now 800px from the top of the page. This change causes the 'up' flavored callback to fire on the next throttled scroll.

First, and this may sound weird, I'm glad this is happening. A change in scrollOffset through the waypoint's offset value really should trigger the waypoint, and it's position shouldn't automatically be recalculated. Those recalculations only happen automatically on window resizes and when waypoints are added.

Second, there's something to handle this type of scenario already, thank goodness. The refresh function. From that documentation (emphasis added):

This will force a recalculation of each waypoint’s trigger point based on its offset option. This is called automatically whenever the window is resized, new waypoints are added, or a waypoint’s options are modified. If your project is changing the DOM or page layout without doing one of these things, you may want to manually call this refresh.

Making the call after you change classes within the callback should force the recalculation before the next scroll check and things should be good. Give it a try and let me know how it works.

[imakewebthings]

@neilpowers Any update on using the method above?

[neilpowers]

Hi Caleb, I have been using the fixed height wrapper solution for the time being. I tried the refresh option but it didn't appear to work in my quick test. On a future iteration on the project i will further investigate the refresh approach. Thank you very much for your help with this. cheers Neil