Skip to content
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

Sticky: Add option to have a different waypoint as the sticky element [PullRequestAvailable] #528

Open
axe312ger opened this issue Oct 19, 2016 · 9 comments · May be fixed by #529
Open

Comments

@axe312ger
Copy link

I often had the case, that I wanted to use the sticky shortcut. But mostly it was useless, since I wanted some other element to trigger the sticky, not the element itself.

For example a header above a slideshow. The header should get stuck after the slideshow, not directly when opening the page and overlaying the images in the slideshow.

Api changes

stickyElement new option for sticky plugin. Fallback is the normal element option, so the plugin behaves as before when this new option not set.

Code changes

In https://github.com/imakewebthings/waypoints/blob/master/src/shortcuts/sticky.js#L21 we should use stickyElement if it is set, otherwise just use the wrapper.

What do you guys think? I will provide a pull request when somebody else could use this feature :) Would love to see it in 4.1.0

@axe312ger axe312ger changed the title Sticky: Add option to have a waypoint which itself is not the sticky element Sticky: Add option to have a different waypoint as the sticky element Oct 19, 2016
@tilwinjoy
Copy link

I have similar use case as well. When the top of a huge section scrolls into view, I need to make an element at the bottom of this section (outside viewport) stick to the bottom of the viewport.

At the moment I have to make the waypoint on the top of this huge section and then do the stuff that sticky does on the other element manually... This seems like a solid use case.

@axe312ger
Copy link
Author

axe312ger commented Oct 21, 2016

@tilwinjoy Feel free to try my branch/PR: #529

The only issue while using css animations with my branch was that the wrapper height was reset to early. So I came up with this:

const waypoint = new window.Waypoint.Sticky({
  element: $('#header')[0],
  triggerElement: $('#header-waypoint')[0],
  handler: function (direction) {
    this.$wrapper.height(this.$element.outerHeight(true))
    this.$element.toggleClass('unstuck', direction === 'up')
  }
})

unstuck triggers the hide animation of the header

@rdrewniak
Copy link

@axe312ger, I've implemented your branch and found it extremely useful. Thank you very much for that. I am, however, experiencing some issues (more likely than not, it's caused by my implementation or a logic error). Could I pick your brain to try and decypher where I'm going wrong with all of this?

I have it rigged up so that there's a sticky trigger element which is dynamically positioned to be the exact viewport height from the bottom of the containers that I want to stick. This way, I can have the "stuck" class fixed to the bottom of the screen, as opposed to the top.

It appears that as long as the content spans a larger height than the viewport, it seems to work fine. but if the content is smaller than the viewport, it seems to jump to the top of the screen (most times from about the halfway mark). Here's the URL for my development site. Could I trouble you to have a peek at my site, and see if there's anything that's jumping out at you that I haven't got working quite right?

I know it's a ridiculously ambiguous question, but I'm at my wits end, and I don't even know where to begin fixing this.

[http://cirys.g-squareddev.com/]

@axe312ger
Copy link
Author

I guess you should place the sticky trigger outside of the element you actually attach “stuck” to. So u avoid confusing waypoints with the actual trigger position.

On 17 Nov 2016, at 21:16, Ryan Drewniak [email protected] wrote:

@axe312ger https://github.com/axe312ger, I've implemented your branch and found it extremely useful. Thank you very much for that. I am, however, experiencing some issues (more likely than not, it's caused by my implementation or a logic error). Could I pick your brain to try and decypher where I'm going wrong with all of this?

I have it rigged up so that there's a sticky trigger element which is dynamically positioned to be the exact viewport height from the bottom of the containers that I want to stick. This way, I can have the "stuck" class fixed to the bottom of the screen, as opposed to the top.

It appears that as long as the content spans a larger height than the viewport, it seems to work fine. but if the content is smaller than the viewport, it seems to jump to the top of the screen (most times from about the halfway mark). Here's the URL for my development site. Could I trouble you to have a peek at my site, and see if there's anything that's jumping out at you that I haven't got working quite right?

I know it's a ridiculously ambiguous question, but I'm at my wits end, and I don't even know where to begin fixing this.

[http://cirys.g-squareddev.com/ http://cirys.g-squareddev.com/]


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #528 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ABqBQiwaN8Y6vbEuvmz_kTCBvLfuP6mUks5q_LY4gaJpZM4KbKgz.

@rdrewniak
Copy link

So, in essence, having the triggers placed between each of the sticky wrappers, instead of within the sticky element?

On Nov 17, 2016, at 1:23 PM, Benedikt Rötsch [email protected] wrote:

I guess you should place the sticky trigger outside of the element you actually attach “stuck” to. So u avoid confusing waypoints with the actual trigger position.

On 17 Nov 2016, at 21:16, Ryan Drewniak [email protected] wrote:

@axe312ger https://github.com/axe312ger, I've implemented your branch and found it extremely useful. Thank you very much for that. I am, however, experiencing some issues (more likely than not, it's caused by my implementation or a logic error). Could I pick your brain to try and decypher where I'm going wrong with all of this?

I have it rigged up so that there's a sticky trigger element which is dynamically positioned to be the exact viewport height from the bottom of the containers that I want to stick. This way, I can have the "stuck" class fixed to the bottom of the screen, as opposed to the top.

It appears that as long as the content spans a larger height than the viewport, it seems to work fine. but if the content is smaller than the viewport, it seems to jump to the top of the screen (most times from about the halfway mark). Here's the URL for my development site. Could I trouble you to have a peek at my site, and see if there's anything that's jumping out at you that I haven't got working quite right?

I know it's a ridiculously ambiguous question, but I'm at my wits end, and I don't even know where to begin fixing this.

[http://cirys.g-squareddev.com/ http://cirys.g-squareddev.com/]


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #528 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ABqBQiwaN8Y6vbEuvmz_kTCBvLfuP6mUks5q_LY4gaJpZM4KbKgz.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub #528 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AJZaB8bOcPnN0sjr_LFbAKWO5h6SYECJks5q_LfOgaJpZM4KbKgz.

@axe312ger
Copy link
Author

Yes i guess that might fix your issue. I see the problem only happening at your second sticky background.

On 17 Nov 2016, at 21:43, Ryan Drewniak [email protected] wrote:

So, in essence, having the triggers placed between each of the sticky wrappers, instead of within the sticky element?

On Nov 17, 2016, at 1:23 PM, Benedikt Rötsch [email protected] wrote:

I guess you should place the sticky trigger outside of the element you actually attach “stuck” to. So u avoid confusing waypoints with the actual trigger position.

On 17 Nov 2016, at 21:16, Ryan Drewniak [email protected] wrote:

@axe312ger https://github.com/axe312ger, I've implemented your branch and found it extremely useful. Thank you very much for that. I am, however, experiencing some issues (more likely than not, it's caused by my implementation or a logic error). Could I pick your brain to try and decypher where I'm going wrong with all of this?

I have it rigged up so that there's a sticky trigger element which is dynamically positioned to be the exact viewport height from the bottom of the containers that I want to stick. This way, I can have the "stuck" class fixed to the bottom of the screen, as opposed to the top.

It appears that as long as the content spans a larger height than the viewport, it seems to work fine. but if the content is smaller than the viewport, it seems to jump to the top of the screen (most times from about the halfway mark). Here's the URL for my development site. Could I trouble you to have a peek at my site, and see if there's anything that's jumping out at you that I haven't got working quite right?

I know it's a ridiculously ambiguous question, but I'm at my wits end, and I don't even know where to begin fixing this.

[http://cirys.g-squareddev.com/ http://cirys.g-squareddev.com/]


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #528 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ABqBQiwaN8Y6vbEuvmz_kTCBvLfuP6mUks5q_LY4gaJpZM4KbKgz.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub #528 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AJZaB8bOcPnN0sjr_LFbAKWO5h6SYECJks5q_LfOgaJpZM4KbKgz.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #528 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ABqBQqczCtop_sSJi_lFQuK2wvzPwbDfks5q_LxngaJpZM4KbKgz.

@rdrewniak
Copy link

That seems to have worked. Thanks a million for your help! :-)

On Nov 17, 2016, at 1:44 PM, Benedikt Rötsch [email protected] wrote:

Yes i guess that might fix your issue. I see the problem only happening at your second sticky background.

On 17 Nov 2016, at 21:43, Ryan Drewniak [email protected] wrote:

So, in essence, having the triggers placed between each of the sticky wrappers, instead of within the sticky element?

On Nov 17, 2016, at 1:23 PM, Benedikt Rötsch [email protected] wrote:

I guess you should place the sticky trigger outside of the element you actually attach “stuck” to. So u avoid confusing waypoints with the actual trigger position.

On 17 Nov 2016, at 21:16, Ryan Drewniak [email protected] wrote:

@axe312ger https://github.com/axe312ger, I've implemented your branch and found it extremely useful. Thank you very much for that. I am, however, experiencing some issues (more likely than not, it's caused by my implementation or a logic error). Could I pick your brain to try and decypher where I'm going wrong with all of this?

I have it rigged up so that there's a sticky trigger element which is dynamically positioned to be the exact viewport height from the bottom of the containers that I want to stick. This way, I can have the "stuck" class fixed to the bottom of the screen, as opposed to the top.

It appears that as long as the content spans a larger height than the viewport, it seems to work fine. but if the content is smaller than the viewport, it seems to jump to the top of the screen (most times from about the halfway mark). Here's the URL for my development site. Could I trouble you to have a peek at my site, and see if there's anything that's jumping out at you that I haven't got working quite right?

I know it's a ridiculously ambiguous question, but I'm at my wits end, and I don't even know where to begin fixing this.

[http://cirys.g-squareddev.com/ http://cirys.g-squareddev.com/]


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #528 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ABqBQiwaN8Y6vbEuvmz_kTCBvLfuP6mUks5q_LY4gaJpZM4KbKgz.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub #528 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AJZaB8bOcPnN0sjr_LFbAKWO5h6SYECJks5q_LfOgaJpZM4KbKgz.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #528 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ABqBQqczCtop_sSJi_lFQuK2wvzPwbDfks5q_LxngaJpZM4KbKgz.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub #528 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AJZaB3f1Yq_zV1RtSkMGrXhJor1rq4Iyks5q_LyygaJpZM4KbKgz.

@axe312ger
Copy link
Author

Hey there @imakewebthings, looks like people enjoy my pull request. Any chance to get it merged? :)

@axe312ger axe312ger changed the title Sticky: Add option to have a different waypoint as the sticky element Sticky: Add option to have a different waypoint as the sticky element [PullRequestAvailable] Dec 26, 2016
@axe312ger
Copy link
Author

Everyone who is looking for the code, can find it here: #529

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants